Use a better directory when installing code via the update manager (documentation followup)

Should there be some variable available that can set it to install to sites/all? I would like to have that as an option somehow so that in multisite installs I do not need to separately download the files for each site (but I would expect to run the updates separately since I see no other way around that.).

Either that or do not encourage the use of sites/all in the documentation? Sites/default should cover most people that are not using multisite.

(subscribe)

The issue is kinda complicated. Here is the gist of why it is this way:

1. We don't want to cause problems for multisite by upgrading a module in one site and having it affect another site.

2. sites/default comes after sites/all when looking for modules so if the same mod is ver 1 in sites/all and ver 2 in sites/default the modules page will find ver 2. So when upgrading a module in sites/all we put a copy of the new version in sites/default. Not ideal, but best worst case AFAICT.

3. Our docs to say to put your mods in sites/all... this sucks. We used to have a variable to make updates go to sites/all if desired, we should perhaps add this back. In which case, we should change the issue title.

Some thoughts: Update manager will produce the greatest work savings for people who are using multisite, so not good to neglect sites/all. I don't think it would be proper to say, "Since update manager streamlines module updating, we can install a separate copy of the same module for each site in a multisite install," because this is inefficient.

Since it is "update manager" and not "play hide-and-go-seek with your installed modules", the following should always be true:

• module/theme in sites/default only ⇒ update to sites/default.
• module/theme in sites/all only ⇒ update to sites/all. Give a warning about other sites, perhaps before the update begins.
• module/theme in sites/example.com only ⇒ update to sites/example.com.

The only cases that should be considered for special behaviour are:

1. module/theme in sites/all and sites/default ⇒ ?
2. module/theme in sites/all and sites/example.com ⇒ ?
3. (module/theme in sites/default and sites/example.com) will never occur?
4. module/theme in sites/all and sites/default and sites/example.com ⇒ ?

...and their sub-cases where the currently installed versions are mismatched in various ways.

For example, #1 and #2: if the version in sites/all is already older than the other version, do not use sites/all. If the versions are equal, update both. If the version in sites/all is newer, assume some other site does not have a duplicate install of that module and it will be updated from there.

@Paul, you make sense, but there is a pretty serious complication there too:

DomainA and domainB are both using views and it is in sites/all.

Admin logs into DomainA and tried to upgrade views.

The process runs, the views code base is replaced and there are numerous DB updates. Even if we get DB updates working with code updates (there is another issue somewhere), DomainB is totally FUBAR in the meantime as views has just F%^&ked a chicken.

There is no way out of this... Given the way multisite operates, I don't see how we could cleanly run updates for other sites either :(

Suggestions?

I like the idea to have a variable to set the download directory for the site.

One site can have it as sites/all, the other can have the more specific one, so the "less important" sites can use sites/default or sites/mydomain.com and upgrade the modules for that site, while the main site can upgrade it for them all.

Another way that would probably be too late for Drupal 7 and that is a way to upgrade multiple sites within one UI - have a "master site" from which when updating, updates are run for all the sites, where each multisite folder is ran through, updates checked and carried out.

@Jacob: in a perfect world, the update manager could identify that DomainB (and not DomainC) is using the module, take that site offline, and restore it afterwards, in parallel with DomainA. Or, modules would be sensitive to the current installed database schema and refuse to run if the schema version does not match the code version (instead of blindly f^*&ing chickens :). Currently I'm pretty sure that's not possible.

So, a more limited approach may work. Specifically, can it do something like:

1. Look for all settings.php files.
2. Do a DRUPAL_BOOTSTRAP_VARIABLES or other limited inspection of those sites.
3. Refuse to proceed if some/all of those sites are online.

...or is that a total no-go?

@paul - that is also troublesome - upgrading one site in a multisite setup should not bring all the other sites down, or reduce their functionality.

The way around this is to either play dumb as it is/will do currently, letting the people so things for themselves or to have method to run the update code on all of the sites. Trying to be more clever will get people into trouble.

@dww: That's how it used to work, and how I originally spec'd it.

see http://groups.drupal.org/node/24709 for why it is the way it is now.

I dunno. Anyway, I think it's not so bad the way it is now. You know why? Because we're not overly concerned with people upgrading from sites/all -> sites/modules. Most people using this will be starting from scratch and only installing modules with this tool IMO (unless we get D6-D7 upgrades happening). Our user base shouldn't even be looking at the shell.

Then, I also agree that multi-site is full of people who use drush anyway.

Putting it back is fine by me, but I think that perhaps a simple setting with a UI:

"Install new modules and themes" for
o All Sites
o Just http://iamthissite.com

Might be a good idea.

@dww: I am openly pushing the multi-site barrow here. I fully agree with your point in (A) that multi-site considerations shouldn't make single-site behaviour unintuitive. But I run three, 4+-site installs and 0 installs that are not multisite, and your (C) is wrong; I want to run update manager myself! I do this for fun, but this is also the use-case of the small-scale web-developer hosting several of his/her clients on one install.

Current upgrade process is:

1. Web: Log in to each site as UID 1.
2. Web: Take each site offline.
3. Shell or FTP client: Download and extract sites/all updates.
4. Shell or FTP client: Download and extract sites/example1.com, sites/example2.com, sites/example3.com and sites/example4.com updates.
5. Web: Run update.php on each site.
6. Web: Put each site online.

#3 and #4 are the most time-consuming and tedious part. Hopefully, at the very least:

1. Web: Log in to each site as UID 1.
2. Web: Take example[234].com offline.
3. Web: Run update manager from example1.com. sites/all and sites/example1.com updates are installed; database updates occur automagically (I think?).
4. Web: Run example[234].com/update.php (for sites/all updates).
5. Web: Run update manager from example[234].com. sites/example[234].com updates are installed; database updates occur automagically.
6. Web: Put each site online.

If this second process ends up juggling modules all over the place or shoehorning everything into sites/all, update manager will be useless to me and I will be sad (or file bugs).

...though now that I reread, I notice this is only for installing new code, not for updates, and I'm a complete idiot.

"I can't fathom why you'd rather do this [...] via the web UI than [...] a [...] shell script" — isn't this the reason for using a CMS in the first place? The relative ease of each is just a function of how much development effort, to date, has been put into drush and update manager. Also, "the new drush is a separate program from drupal that lives outside of web root." If update manager can eventually update core, including itself, then that's a further advantage over a separate application that must also be updated separately.

Crell also suggested at #538660-118: Move update manager upgrade process into new authorize.php file (and make it actually work) "We should just pinch code from Drush to see how it decides between sites/all and sites/default and do whatever it does." Although Jacob doesn't give a shit (with a smiley), it's still worth taking a look:

function pm_dl_destination($type) {
  ...
  // Attempt 1: If we are in a specific site directory, and the destination directory already exists, then we use that.
  ...
  // Attempt 2: If the destination directory already exists for sites/all, then we use that.
  ...
  // Attempt 3: If a specific (non default) site directory exists and sites/all does not exist, then we create destination in the site specific directory.
  ...
  // Attempt 4: If sites/all exists, then we create destination in the sites/all directory.
  ...
  // Attempt 5: If site directory exists (even default), then we create destination in the this directory.
  ...
  // Attempt 6: If we didn't find a valid directory yet (or we somehow found one that doesn't exist) we always fall back to the current directory.
  ...

By "the destination directory", it refers to a subdirectory named "modules", "themes", etc. as appropriate on a case-by-case basis. This is similar to what I suggested above, and not very complicated. For now, to limit scope, perhaps trust multi-site users to know what they are doing and coordinate DB updates properly...at most provide a warning.

this system by design will never work for multi-site

put stuff in sites/all

if you are using multi-site and you break your sites it's your own damn fault for not using drush.

ARGH!

Adrian!!! This is what I had originally, and you made me change it because it would break multi-site! What you are saying is an almost exact quote of my argument to you about the same thing.

heh, anyway, I'm glad we agree now xD

Best,
J

i also pretty happy to end up puttng stuff in sites/all by default. make it so, wizards.

@adrian: Please try to be less touchy about drush; if you reread #13 you'll note it suggests following drush as an example of best practice. The "this is a different and thus inferior way of doing something my code can do" attitude is also behind the ugly pro-/anti-Mono food fight that reflects so poorly on Free Software.

Anyway, I can't swim against the tide, since I don't have the time to produce code. It's just a big letdown to be unable to use update manager after eight months of excitement about having it in core.

I'm not quite sure if this should be a separate issue but it seems it could be related. I just attempted this:

Site had D7 installed.
Site name:d7lh (using the d7lh directory)
Earlier installation of the dhtml_menu module in /sites/all/modules
Update by ftp to localhost

Upon running the update of the module it failed saying it could not stat

/docroot/sites/d7lh/modules/dhtml_menu

Indeed there is no directory at:

/docroot/sites/d7lh/modules/dhtml_menu

The contents of the dhtml_menu module have been unpacked so that

/docroot/sites/d7lh/modules/dhtml_menu.install
/docroot/sites/d7lh/modules/dhtml_menu.module

etc exist.

If this should be a separate issue let me know and I'll re-open it there.

That is weird, it should never install in DRUPAL_ROOT / modules.... Should always be in sites/all or sites/default, can you check your system table to see where Drupal thinks it is installed?

-J

Subscribing.

I'm trying to wrap my head around the update manager, but I really don't understand why there's no easy/obvious way to change the folder that Drupal is updating. To give one example I just downloaded and installed the latest dev version of Admin_Menu via CVS in the usual place (sites/all/modules). I then went to the update manager screen, selected Admin_Menu and clicked "Update", which white screens on my Vista/XAMPP install. But, even worse is that I now have a duplicate version of the module at sites/default/modules and can't see any way to tell which version I'm now using (I'm guessing it's the one at sites/default/modules).

At the very least I think there should be some indication on the module administration page as to where the module I'm using is located, otherwise this seems like a good recipe for mass confusion.

jbrauer, Alex—have you used drush in the past? If not, what do you think of the logic copied from its code at #13? From the way you describe your respective situations, it would have succeeded at "Attempt #2", i.e. replacing the module versions in sites/all/modules.

@jbrauer: Eek. I see the issue now... that is strange.

I don't know how to debug that exactly, It's obviously copying "into" the directory, which it is not supposed to do.

Do you have the ftp extension enabled? or did it use the wrapper (the stream wrapper was a little buggy in this regard previously).

BEst,
J

I tried my best to break this and couldn't. I installed modules and themes manually in both sites/all and sites/default, and I installed modules and themes via update manager. All the updates put everything exactly where it belonged, and the installations went to sites/all. Makes sense on code review as well. This is really a lovely improvement.

This is a great solution to a really critical bug. Thanks for solving it on such short notice!

Committed to HEAD.

This is awesome, thanks!

Just a question: what happens if you don't have write access to sites/all? Does (as it should IMHO) fall back to installing the new module to sites/mysite/modules?

Re-closing. @miiimooo - please open a new issue for that question, if you have problems with the functionality. Otherwise, test it out and see what happens :)

Hi, I'm sorry to reopen this but while reading the update code in includes/updater.inc, I found a comment that just didn't make since. Searching through the issues I got here, which seems to strongly indicate that the comment is wrong and should be removed. Please see attached patched.

OK, here's the same patch as a Git patch. This should make the bot happy.

I assume the comment is wrong in Drupal 8 too? If so, needs a reroll for that.

Nope, the comment is not present in D8. That was the first thing I checked. I should have mentioned that - sorry.

Added: I did not intentionally edit the tags.

@hansfn, I see it in core/lib/Drupal/Core/Updater/Updater.php:

      // Note: If the project is installed in the top-level, it will not be
      // deleted. It will be installed in sites/default as that will override
      // the top-level reference and not break other sites which are using it.

It's worded slightly differently, but I believe it's also incorrect?

Very good catch, David. I didn't check carefully enough.

This is the patch

Since the main problem was fixed a while ago, let's fix the documenation bug on #2488420: Remove a misleading comment from Updater::update().

Agreed. But for sanity's sake let's set this back to the version the original issue was actually fixed in.