Is it possible to perform a single module's update function via drush? I can see drush updatedb which does not take an modulename as argument and runs all available updates. Then there is drush pm-update wich also checks for new files. the documentation says:

(same as pm-updatecode + updatedb)

Does this mean if I run drush pm-update every available (newer update_function exits) update will be perfomed? Is there a way to only (db)update exactly one module?

  • I know this question is quite old, but I'm curious: Why would you want that? Normally, all code is based on the assumption that the db is up-to-date. If you don't want the db update of a specific module to run, shouldn't you revert the entire module to an earlier version? Mar 13, 2013 at 22:20
  • 1
    one year later. I needed this for the following: I've made a custom module, but changed the table layout later on (still in the development stage), so this would've be handy to just update the db with the new schema. Mar 6, 2014 at 8:39

6 Answers 6


No, you can't.

If you want to update each module on their own, only update the files of a single module and then run updatedb.

  • See comment below about using drush dl (you probably want to delete the old module first so you don't keep around older files not intended for the new version!)
    – doublejosh
    Nov 30, 2012 at 0:03
  • Is there a way to do this outside of drush?
    – lathomas64
    Jan 8, 2014 at 14:16
  • 2
    @ahimsauzi gave the correct answer Jun 3, 2014 at 12:12

On Drush 5.7 you can run the command drush pm-update --no-core module-name. Drush will automatically backup the current module, download the new version and prompt you to update the database.

  • 6
    That will run ALL pending updates, not just ones from the module you updated. Nov 1, 2013 at 18:52
  • Moshe, can clarify? I have been running the above command and although Drush will check ALL pending updates, only the module specified (module-name above) will be updated. Am I missing something?
    – ahimsauzi
    Nov 3, 2013 at 0:31
  • 7
    It check all pending code updates and only update the code for the specified module, but it will process all database updates.
    – meustrus
    Dec 4, 2013 at 22:47

If you want to run just one update, you can run drush eval foo_update_33(), for example. In practice, it is a little more complex than that as you have to load the .install file but not much.

You can also try @macaleaa solution :

drush php-eval 'module_load_install('my_module');my_module_update_7XXX();'

  • 4
    I will add that it would be great if someone made a a Contrib extension for Drush that let you run selected updates. Thats not a safe thing to do in general, but sometimes you gotta live dangerously. Not appropriate for core Drush though (I am the Drush maintainer) Nov 1, 2013 at 18:53
  • 3
    Why not appropriate for core drush? Isn't it possible that someone would want to enforce a particular order of database updates (for code already downloaded), in which case each individual module would need to be updated separately? I'm in such a situation myself.
    – meustrus
    Dec 4, 2013 at 22:50
  • where is the 33 coming from here? is foo the machine name of the module?
    – lathomas64
    Jan 8, 2014 at 17:53
  • The 33 is part of the name the update function and determines the order. And yes, foo is the machine name of the module. You can find the functions in foo.install. For example, the devel module (in devel.install) has several update functions: function devel_update_7000 is the one with the lowest number, and will get executed first, then function devel_update_7001, etc.
    – Ursula
    Jan 8, 2014 at 20:13
  • 3
    Here's an example that loads the install file first:drush php-eval 'module_load_install('file_entity');file_entity_update_7211();'
    – mcaleaa
    Jan 27, 2014 at 14:22

neither drush up someproject, nor drush upc someproject seem seem to update only the someproject module. A different way to that what you want is through :

drush dl someproject #use --select option to be prompted for a module version
                     #this will overwrite your exising module's files
                     #backup your modules files with --backup, yourself, use a VCS to revert
drush updb           #run available database update scripts

Here is discussion a similar topic on Drupal.org. Take care !

  • I just tried, and drush up someproject DOES work, BUT unfortunately it checks ALL the available updates for enabled modules by default too (which would not be needed), writes "Update available" to some of them, but ONLY updates the specific project. Here is a screenshot: i.imgur.com/TDDmB.png. As you can see, multiple updates are available, but only xmlsitemap gets updated using drush up xmlsitemap.
    – Sk8erPeter
    Dec 10, 2012 at 0:02

I'm using Drush 5.9, & can update a single module successfully with this command:

drush dl *project*

So, for example, to update the 'devel' module:

drush up devel

I had a situation in which a table created by an update function (MYMODULE_update_7101), but that table was being accessed in code somewhere in every cache clear and almost every drush call (it was basically getting the names of entity types for all the menus and whatever else). Running drush updatedb was running MYMODULE_update_7101 third instead of first.

I tried the solution suggested by @macaleaa and @moshe weitzman of running:

drush php-eval 'module_load_install('MYMODULE');MYMODULE_update_7101();'

before running drush updatedb, but this didn't help - the drush run failed because updatedb tried again to run MYMODULE_update_7101() and errored out, saying the table already existed. Basically, the above code had run the update, but not left its mark on the system that the update had been run. Presumably there is a whole bunch of other stuff update.php has to do after running each update to store the latest version number for the module in the db, etc.

I went through update.php to see how it actually runs each update function and what it does after, looking for a function to call that would call the update function and also do all the other stuff. I ended up getting to this:

include_once DRUPAL_ROOT . "/includes/update.inc";
$c["results"]["#abort"] = array();
update_do_one("MYMODULE", 7101, array(), $c);

Which I actually ran with drush:

drush eval 'include_once DRUPAL_ROOT . "/includes/update.inc"; $c["results"]["#abort"] = array(); update_do_one("MYMODULE", 7101, array(), $c);'

It ran the update, no problem, but then MYMODULE version 7101 still showed up in the updates list when I ran updatedb, ALTHOUGH it ran without erroring out and everything looked good on inspection of the site.

A bit hacky and 6 years late, but all's well that ends well?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.