Posted by Owen Barton on November 15, 2008 at 1:18am
4 followers
Jump to:
| Project: | Drush |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I have noticed that many users have trouble running drush because (a) it doesn't figure out their Drupal root and uri correctly, especially if they use symlinks and (b) it doesn't have helpful error messages when these are missing.
This patch attempts to resolve this by:
- Using $_SERVER['PWD'] when available, so we get the actual path the user is running the command from without resolving symlinks. Before, if you had mysite.com symlinked in drush would not find the drupal root directory from the mysite.com directory - even if you were actually in the www/drupal/sites/mysite.com directory. Now it does.
- It checks if the current directory has a settings.php in it, drush now assumes that that is the site you want to run (if there is no -l parameter). If settings.php has a configured $base_url it will use that. If not it will try and use the current directory name, which would be mysite.com in a multisite. Obviously the latter is somewhat fallible, and doesn't deal with domain.subdirectory site names, but I think it is worth attempting.
- We only call _drush_locate_root() once now, rather than twice (which is nice since it does a lot of walking and checking) - this change is a side effect of the above check.
- All the low level error messages are now in the standard 'E:' format, and all use die()
- They also give a hint, pointing people at the likely option that will resolve that error.
| Attachment | Size |
|---|---|
| drush_php_intelligence.patch | 7.42 KB |
Comments
#1
I tested this and nothing broke. I use subdirectories for all my dev sites so I could not test the autodetect stuff. Anyway, please commit along with a HEAD version. Thanks Grugnog2.
#2
Autodetection works like a charm on my *nix system on several D6 installations with multisite setups.
#3
Committed this yesterday
#4
There is a slight flaw in the $base_url auto-detection logic: At some point it actually does a require_once() on the settings.php file, which will crash if you happen to have any logic in there that depends on the real Drupal bootstrap sequence. Take a look at custom_url_rewrite_inbound() and related "hooks", for instance.
If "settings.php" was loaded as a string instead, a fairly simple preg_match could extract the value of $base_url.
The vast majority of Drupal/drush users will never notice this, so it's not of paramount importance.
#5
Automatically closed -- issue fixed for two weeks with no activity.