Drush command for running update.php

no, it isn't. thats an interesting idea though.

Moshe-

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.

As 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.

nice example code at http://drupal.org/node/233091.

I 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)

revert change to issue title

And 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 ;)

subscribe

subscribe

Here 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:

  php sites/all/modules/contrib/drush/drush.php update

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:

  php sites/all/modules/contrib/drush/drush.php update force

If there is nothing to update, it will show you the current version and exit.

Here is what it can show you:

statistics                      1000
system                          1022
content                         1008
number                             5
optionwidgets                      1
text                               5
date                            5104
fckeditor                          3
lightbox2                          3
link                               1
messaging                          2
nodequeue                       5204
notifications                      6
taxonomy_redirect                  2
token                              1
views                             16
devel                              3 ->     5 (4, 5)

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.

Will this update all sites in a multisite-setup or just one site?

@lomz - I expect it to follow the normal drush style which is that it will respect the -l example.com switch.

folks - we need to get this into d7 and d6 which means supporting batch API syntax for updates.

@greggles - could you explain a little further?

Will this update all sites in a multisite-setup or just one site?

I 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.

Adrian's D6 code: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/provision/p...

has to handle batch api style updates.

@moshe: The batch API is in D6 and/or D7, right? Maybe the version of this issue should be changed to D7?

I 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).

I 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.

function drush_platform_include(&$data, $path, $command, $version = null, $platform = 'drupal') {
  $version = ($version) ? $version : drush_drupal_major_version();
  $options[] = sprintf("%s_%s_%s", $platform, $version, $command);
  $options[] = sprintf("%s_%s", $platform, $command);
  $options[] = sprintf("%s", $command);

  $match = false;
  foreach ($options as $option) {
    $file = sprintf("%s/%s.inc", $path, $option);
    if (file_exists($file)) {
      $match = $file;
      break;
    }
  }

  if ($match) {
    drush_log(dt('Including platform specific file : @file', array('@file' => $match)));
    include_once($file);
  }
}

So at a later point where I wanted to have the code execute, I could just do :

  provision_platform_include($data, dirname(__FILE__), 'update');

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.

I think putting this in drush_extras makes perfect sense.

Note 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.

subscribe

We 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.

I 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

subscribe

committed the provision update commands.