Closed (fixed)
Project:
Drush
Component:
Code
Priority:
Minor
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
25 Aug 2009 at 23:45 UTC
Updated:
7 Oct 2009 at 10:20 UTC
What is the difference between first running updatecode and then updatedb compared to just running update?
I thought update was updatecode and then updatedb but I get an error if I run update but not if I run updatecode and then updatedb.
Running updatecode:
Refreshing update status information ...
Done.
Update information last refreshed: Wed, 2009-08-26 01:25
Update status information on all installed and enabled Drupal modules:
Name Installed version Proposed version Status
Drupal 6.13 6.13 Up to date
No code updates available. [ok]
Running updatedb:
No database updates required [success]
Finished performing updates. [ok]
Running update:
Refreshing update status information ...
Done.
Update information last refreshed: Wed, 2009-08-26 01:25
Update status information on all installed and enabled Drupal modules:
Name Installed version Proposed version Status
Drupal 6.13 6.13 Up to date
No code updates available. [ok]
Drush command could not be completed. [error]
[...] (Drupal HTML output)
An error occurred at function : drush_pm_post_update [error]This applies both to All-Versions-2.0 and All-Versions-HEAD.
In my setup there was no modules that needed updates, I think read somewhere that there's an error in update if there is no updates availably, maybe that's the same error?
Comments
Comment #1
jonhattanAdrianB: try it with --debug flag to see if we can get more info.
The difference when calling `update`is that `updatedb` is called through the backend (ie, in a separate process).
Perhaps the ommited (Drupal HTML output) is a backend dump and not drupal?
Comment #2
AdrianB commentedI if run
update --debugI get this:The Drupal HTML output that i removed is this:
Comment #3
jonhattanThose issues seems similar to yours: #454010-3: Site is not fully installed? login details are not received, and modules are not installed and #516544: Hung up @ 'hosting setup' .
Comment #4
jonhattanops, unintentionally I changed the status. Reverting to active.
Comment #5
AdrianB commentedWell, it's not a big issue, I'll just use updatecode + updatedb instead of update. I just wanted to report the issue.
Comment #6
markabur commentedjust wanted to chime in and say that the same thing happens to me. i run drush on a variety of server configurations and for a bunch of different sites, and i've never seen update run without the drush_pm_post_update error. i always have to run updatedb separately. i've checked the php error log and the drupal log and don't see anything there.
Comment #7
markabur commentedok, after a little digging i found the source of the problem for me. on line 329 of backend.inc,
the "php" there is not the php i use to run drush -- rather, i'm using the php that's part of MAMP. the solution is to link the MAMP php to the system php as described here:
http://raincitystudios.com/blogs-and-pods/steve-krueger/how-use-drush-lo...
Comment #8
AdrianB commentedAha, you found it markabur!
Line 329 has "php" hard coded and does not honor the php path that is used when I run drush.
My alias in .bash_login looks like this:
alias drush='/Applications/MAMP/bin/php5/bin/php ~/path/to/drush/drush.php'This is what the drush README.txt suggest and it makes drush use this specific php installation. But when line 329 is run then the standard php is used instead.
To confirm this I change this part of line 329:
escapeshellcmd("php %s %s %s --backend")to specifically use my MAMP php:
escapeshellcmd("/Applications/MAMP/bin/php5/bin/php %s %s %s --backend")And voila!
drush updateis run with no errors.Of course, this is bad solution. A better one is that to create a link like the one in the raincitystudios.com article:
$ sudo ln -f /Applications/MAMP/bin/php5/bin/php /usr/bin/phpThis works (I assume, I haven't tested it myself), but then you're forcing every php request to use MAMP php and that may not be what you want.
An even better solution would be to make drush to use the same php as it was initialized with. I don't know how to do that, though.
Comment #9
markabur commentedyep, and i realized that although i do run drush in non-mamp contexts, i only ever run the update command on my mac (the code updates are pushed to my servers via svn). so, the error only happens on my mac.
i too am curious if it's possible to make the php command on line 329 more robust by using the same php that drush was initialized with. changing from bug report to feature request..
Comment #10
jonhattanUSing the same php command is possible. There's already a function to find it available in drush. It should be moved off current place to a better location and the name be generalized.
http://drupalcontrib.org/api/function/drush_simpletest_find_php/6
Comment #11
AdrianB commentedjonhattan: Nice, that means that this problem is solvable within drush in a non-hacky way.
Comment #12
moshe weitzman commentedMoved that function to environment.inc and using it here. Please reopen if this is not fixed. I wasn't able to test it easily.
Comment #13
markabur commentedmoshe: works great, thanks.
Comment #14
AdrianB commentedI can confirm that this change (using All-Versions-HEAD from 2009-Sep-23) solves this issue. Thanks to markabur, jonhattan and moshe!
(I do get another warning using All-Versions-HEAD,
array_merge(): Argument #2 is not an arraybut I don't think that's related at all.)