Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Question: is update.php invoked when running "drush pm update module"?
If so, would it be possible to include the update # as an optional parameter?
If not, could we have a "drush pm updatephp module update #"
This feature could be useful for managing multiple domains.
Comment | File | Size | Author |
---|---|---|---|
#10 | 194107.patch | 3.8 KB | roychri |
Comments
Comment #1
moshe weitzman CreditAttribution: moshe weitzman commentedno, it isn't. thats an interesting idea though.
Comment #2
agentrickardMoshe-
skizzo's question comes from some Domain Access testing that he's doing.
For background, see:
- http://drupal.org/node/193008
- http://groups.drupal.org/node/7039
The module Domain Prefix provides a user interface for enabling select database table prefixing for use with subdomains. We're trying to figure out how to update those tables when running update.php.
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedAs far as I can tell, update.php uses a workhorse function called update_data() which calls module_invoke($module, 'update_'. $number); So, I think drush could pretty easily perform specified updates just with module_invoke($module, 'update_'. $number); i don't have time to implement this, but i would review any patch submitted here.
in general, drush should offer to perform all pending updates. specifying an extremely rare use case IMO.
Comment #4
moshe weitzman CreditAttribution: moshe weitzman commentednice example code at http://drupal.org/node/233091.
Comment #5
dlhubler CreditAttribution: dlhubler commentedI wrote a script for running updates from posh (plain old shell)
http://acquia.com/blog/drupal-cli-utils
(some folks in IRC sug. i post here, but they probably didn't realize I wasn't using drush)
Comment #6
dlhubler CreditAttribution: dlhubler commentedrevert change to issue title
Comment #7
gregglesAnd yet another separate post about this http://sachachua.com/wp/2008/09/16/drupal-and-drush-updating-the-databas...
If sacha doesn't find a round tuit to create a patch then I've got it on my calendar ;)
Comment #8
batje CreditAttribution: batje commentedsubscribe
Comment #9
gunzip CreditAttribution: gunzip commentedsubscribe
Comment #10
roychri CreditAttribution: roychri commentedHere is a patch from sacha's code.
I added some extra code that will print anything that was set using drupal_set_message() in order to catch errors and notices that we would not otherwise be able to see.
I also modified the drush_pm to mention that an alternative to update.php is drush update.
To run this code you simply do:
It will show you which version needs to be updated and ask you to confirm.
If you want to update without having to confirm (blind update) then you can pass "force" like this:
If there is nothing to update, it will show you the current version and exit.
Here is what it can show you:
This example tells you that your previous devel version was 3 but the current version is now 5 and the update 4 and 5 needs to be ran.
Comment #11
roychri CreditAttribution: roychri commentedComment #12
lomz CreditAttribution: lomz commentedWill this update all sites in a multisite-setup or just one site?
Comment #13
greggles@lomz - I expect it to follow the normal drush style which is that it will respect the -l example.com switch.
Comment #14
moshe weitzman CreditAttribution: moshe weitzman commentedfolks - we need to get this into d7 and d6 which means supporting batch API syntax for updates.
Comment #15
lomz CreditAttribution: lomz commented@greggles - could you explain a little further?
Comment #16
gregglesI don't know of any drush commands that run the command on all multisites. When we call drush we have to tell it "-l example.com" to get it to work on a particular site. I expect this to work the same: that it executes for one site within a multisite.
Comment #17
moshe weitzman CreditAttribution: moshe weitzman commentedAdrian's D6 code: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/provision/p...
Comment #18
moshe weitzman CreditAttribution: moshe weitzman commentedhas to handle batch api style updates.
Comment #19
roychri CreditAttribution: roychri commented@moshe: The batch API is in D6 and/or D7, right? Maybe the version of this issue should be changed to D7?
Comment #20
adrian CreditAttribution: adrian commentedI have code in provision HEAD for installs and updates for d5/d6/d7.
I have them built as conditional includes, which depend on the VERSION you have bootstrapped. This might not gel with how drush is handling the version specific code (as a separate extras project).
The commands also use the logging, error handling and _invoke api, but ideally I would like to see them move into drush.
The system is built so that commands can either be re-used in the same thread (ie: the pm commands could just call the command internally, or they could choose to execute drush.php update and integrate the output into their own).
Comment #21
adrian CreditAttribution: adrian commentedI think this should be for 2.x, as that's where the main development is going on, and one of the PRIMARY requirements for this to work properly, is that the commands need to be able to run without needing to bootstrap.
There's also a case to be made for moving this to drush_extras. The code needed to update each version of drupal is wildly different.
In provision however, I felt it served me better to not have to manage multiple branches, so I separated all of this code into their own .inc files :
Drupal 5 :
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/provision/p...
Drupal 6 :
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/provision/p...
Drupal 7 :
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/provision/p...
Now that the logging and error handling code is in Drush, and the drush_invoke getting close, the code I wrote should be very portable.
I also wrote a helper function that conditionally includes these files, based on the active drupal version. It should be noted that 'install' and 'update' commands need to have a 'bootstrap' => -1 property set, as the commands themselves need to manage the bootstrap level.
So at a later point where I wanted to have the code execute, I could just do :
This is pretty unlike the way Drush currently does the version specific code (ie: a separate project), so to do it the drush way, and not the provision way, would involve requiring the download of drush extras for that version, and having the update command running in there.
Comment #22
moshe weitzman CreditAttribution: moshe weitzman commentedI think putting this in drush_extras makes perfect sense.
Comment #23
anarcat CreditAttribution: anarcat commentedNote that I submitted a patch for D7 that would ease the implementation of such things, see #233091: Move code from update.php into includes/update.inc. Please review and comment. The idea is to get rid of our code in provision and make Drupal offer a proper upgrade API.
Comment #24
bjaspan CreditAttribution: bjaspan commentedsubscribe
Comment #25
adrian CreditAttribution: adrian commentedWe have decided to move the provision install and update code upstream into drush, which means that drush will get full site install and update functionality , with full support for install profiles and locales, from Drupal 5 through Drupal 7.
Comment #26
adrian CreditAttribution: adrian commentedI have created a new Issue for the porting process, because I felt it would be better to keep everything about the task at hand in the same place: http://drupal.org/node/415152
Comment #27
frankcarey CreditAttribution: frankcarey commentedsubscribe
Comment #28
adrian CreditAttribution: adrian commentedcommitted the provision update commands.