Convenient aliases for running a command on groups of sites

ok, we'll discuss after #727058: Site aliases should not be cached in the options context. As mentioned elsewhere, I have issues with the word multisite here.

It is also very important to consider the impact of #733256: Aliases should be loaded from a central location rather than drushrc.php, which adds new ways that aliases can be grouped together. The concept of an @all alias is clear enough to those who only have one Drupal root, but it becomes a little less clear when there are multiple roots. This is why the current code stopped at /path/to/drupal#all, which though inconvenient to type is at least unambiguous. Perhaps part of what is needed is a way to specify "all" in terms of some alias that defines only a root folder. Addressing all of the aliases in a particular alias file that defines a group of related aliases (e.g. inside servername.aliases.drushrc.php) would also be useful.

This will require more discussion on syntax and such.

I think we might want to add help topics which are not real commands. There we would discuss site aliases. That helps the docs portion of this request without adding a pseudo-command

This can, at least, be un-postponed now.

How about an @all alias that means "all sites in a certain Drupal root"? For example -r /path/to/root @all, @drupalrootalias/@all, /path/to/root/@all?

This is similar in concept to #all, but could be implemented similar to @self.

hmm. nice, but needs less confusing name. i can't think of one in 10 secs. will ponder.

No problem; not critical for 3.0.

@sites?

• drush @sites update
• drush -r /root @sites update
• drush /root/@sites update
• drush @root-alias/@sites update

i like @sites. it matches the 'sites' dir which is the path you take from their 'shared drupal root'.

Just some thoughts about 'inferring' sites on which to execute the drush command. If you cd to a site dir and do a drush command there, drush automatically infers that you want to execute the command on that site, and does not require an argument for that. In (IMHO) analogous way, when using a '@sites', '@multi' or '@multisite' modifier, (here meaning 'multisite' in the original Drupal sense), drush can infer that all sites of this specific docroot are meant. If you mean something else than that, then you should be required to use aliases or whatever other means to specify the exact list of sites on which to operate. So, in other words, drush should assume the 'closest' meaning first and not require the user to always specify the docroot when it is obvious.

Here's a patch that should do the trick. Of the forms shown in #9, all work except for "/root/@sites", since "/root" is not a valid site specification all by itself.

code looks fine. i did not test but i doubt others will without a commit so go ahead.

The patch in #12 didn't actually work for aliases in the form @root-alias/@sites, so what I actually committed is attached here, which does support that form.

With this patch, it would be possible to make aliases @d5, @d6 and @d7 for your various document roots; then @d6/@sites would be an alias for every d6 site in the @d6 sites folder.

Oops - we introduced a critical bug here.

The new call shown at http://drupalcode.org/viewvc/drupal/contributions/modules/drush/includes... eventually leads to $files = drush_scan_directory($base_path, '/settings\.php/', array('.', '..', 'CVS', 'all')); . This line appears to traverse down the whole codebase, including file files directory. Thats no good.

@greg - any chance you can take a look and commit a quick fix?

Sure. You're right, that is too aggressive. The intention was to allow $base_path to be either a drupal root, or perhaps a folder above the drupal root so that you could get all sites available anywhere in a number of different drupal root directories.

For a quick fix, I could make it scan just $base_path/sites/*/settings.php. For the second use case... hm, I wouldn't want to find just _any_ 'sites' directory, as someone might have a copy of 'sites' in the 'files' directory. I'd have to find real drupal roots and then look at sites/*/settings.php inside each.

As long as we don't dive into a modules/themes/files/libraries (new in D7) directory, then I am OK.

This patch renames the parameter $recurse in drush_scan_directory to $recurse_max_depth. Its default value is still TRUE, and the behavior of this function is unchanged when TRUE is passed. When a positive non-zero integer is passed in, it has the effect of limiting the traversal depth of the directory scan.

This new behavior of drush_scan_directory is used to search for 'bootstrap.inc' files inside a specified root directory when building a relative @sites alias. The default maximum search depth for drupal root folders is 1, so if you are searching for @drupal/@sites and the "@drupal" alias is /srv/www/drupal, then only drupal roots immediately inside the 'drupal' folder will be found. This depth can be increased via the --search-depth option.

Note that the search for a drupal root is skipped if the path provided in the alias points to a drupal root ('includes/bootstrap.inc' exists).

When a drupal root is found, drupal sites are searched for, but only the 'sites' folder is checked. Inside the 'sites' folder, the traversal only goes one level deep. This avoids false positives should someone have a settings.php file inside a 'files' folder inside their site folder.

committed.

at this point, i'm afraid to edit the sitealias code for fear of breaking something. its gotten pretty dense. i'd love to see some unit tests here. i think it could just be a drush command that builds out test drupal directory structures (single sites, multi-site) and compares if the aliases return the right number of sites. similarly, we could run a command on several of them at once and compare expected output. at this point, we should just abandon hopes of finding a separate unit test library and just use drush. my .03

Even only scanning the top level of the sites directory, this can still be extremely slow if you have a large multisite installation. I've created an issue with a possible patch here: #801060: Drush 3.0 is extremely slow on a large multisite installation