update modules best practice

michaelbr's picture

I'm not sure if this is the correct place to ask this kind of questions, if not please let me know.

I've been doing module update the following way:
- download the new module from drupal.org
- go to Administer > Site building > Modules then deselect the old module, then click Save configuration
- click Uninstall and select the old module if available, then click uninstall
- remove the old module from sites/all/modules folder
- copy the new module to the sites/all/modules folder
- run update.php

Is this the right procedure to update a module? I've been having lot of db primary key error and I'm not sure if it's caused by my procedure. Should I leave the old module in the folder until I run the update.php, then remove it afterward?

Thanks in advance for your comment/suggestions


Let the updated module do its update thing

victorkane's picture

When you are using a module, it may very well have created a database table to do its work in. So uninstalling it is a bad idea, since that will destroy the database table (if the module's uninstall script is a good one :) ) along with your precious data.

The Drupal way is to update your module by removing the old module code and replacing it with the new (this can be done using a version control system, of course), and then... runing update.php!!!

This script, update.php, should always be run whenever you update a module. What it will do is run any update scripts your module developer has thoughtfully put in for you, which will make any changes it needs to make to any underlying database tables without disturbing your precious data.

Remember, Drupal is a smart system. And you do well to ask about what the proper way is. But the golden rule is simply to run update.php every time you upgrade a module or drupal core.

For example, a new Drupal core release has just come out, Drupal 5.16 / Drupal 6.10

You remove the old Drupal core files and copy in the new files, then... just run update.php

How do you run update.php? If your site is http://example.com, then you need to do the following:

  1. Log in as user #1 (the user you first created when you made the site).
  2. Go to http://example.com/update.php and follow the instructions (just trust the defaults unless you have a really good reason not to).

Victor Kane

Thanks Victor for your

michaelbr's picture

Thanks Victor for your reply, but what's still not clear for me is what I'm supposed to do with the old module, I understand that I have to run the update.php (is it the same update.php in the Administer > Site building > Module and in there there's an update.php link), but should I leave the old module without deleting it or should I delete it after running the update?

Thanks in advance for your suggestion/comment

Thanks in advance for your suggestion/comment

That Old Module...

ScottBaetz's picture

Perhaps I'm a crazy guy... but in very detailed level...when updating to a new module version. I download the new module, put it in a safe place, I take the current contents of the module folder, zip them and store them in a holding location (a folder on your desktop is as good place as any). I then unzip and deploy the new module's contents in the old module folder (which should be empty if you followed the last step) and then I run www.sitename.com/update.php and blindly follow the defaults!

That's always worked for me..

And then I usually delete the holding folder with the old module, frequently wondering why I even kept it!

When I get odd results, I usually run the empty cache routine that devel offers and then the majority of my issues go away.

You could be getting errors like you mentioned - if you've followed the steps you described and the module you 'UNINSTALLED' via Drupal didn't have a clean remove process. It might have left some configuration variables or indexes and when you 'REINSTALL' everything starts to get 'FuNkY'.

my 2 cents..

I believe I said

victorkane's picture

"update your module by removing the old module code and replacing it with the new "

and then

"run update.php" (with the new module in place.

Now, in a special case where you have uninstalled, simply install the new version as if you had never installed before, and if you still have problems, visit the module's issue queue.

Victor Kane

"replace code" = ?

wreford's picture

Thanks for your explanations Victor.

To clarify, I believe that you mean "remove the files from the outdated module's directory" and "put the files from the upgrade module's directory there instead" -- as 'replacing code' is generally what one does when typing in or pasting text into a file.

1. backup database
2. place site in maintenance mode
3. delete the module's folder and replace it with the updated module folder
4. run yoursitename.xyz/update.php
5. take site out of maintenance mode and test

to clarify 3:
replace the folder /sites/all/modules/moduleDirectoryThatYouWantToUpdate/
with the module directory that you downloaded and then uncompressed

This is how I do it with FTP when I don't have ssh access

Please correct me if I'm wrong!

Upgrade went wrong!

jesse24's picture

Hi Victor, I have been looking through the forum trying to find answers to my problem. I have posted my own topic, but thought I would add it here, to see if you or someone could help me.

I have taken over my Mum's eCommerce website over a year ago. It is fairly old with Drupal 5x running and the modules hadn't been updated since it's been in my hands.

I was having problems with FCKeditor, it wasn't showing the correct colour and fonts I had selected, when I was creating a new page and styling text, etc. So I googled it and found that FCKeditor was no longer supported and their is a new one called CCKeditor. So I tried installing this and it did not work.

In the meantime on the modules page majority of the modules were highlighted red, saying it was no longer supported, it needed upgrading or the security needed upgrading. So I selected each one, downloaded the latest versions and uploaded them, overwriting the old modules. I ran the php file to get everything running. Then I received pages upon pages of error messages, at one stage the website crashed. One error message was about imagecache and another image module. So I removed these hoping to clear the error messages on the module page but it did not work, I have now lost all the images in the shopping cart because of this.

I have no idea how to fix this and I probably should of looked into the upgrading before going ahead and doing it. It must be a lot more to it then I first thought.

Could some one please be kind enough to help me, I am desperate!! My mums business is on the line.

Thanking you in advance!

Devel first

aaron's picture

Don't forget the golden rule of always running this on a development server first. NEVER run an update script on a production site until you're certain it won't break your configuration.

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)

Updating to 6.10 from 6.9

prfctpatrn's picture

This is a repeat of an experience I had with my 6.7 to 6.8 update. When doing the 6.10 update as instructed on my server site (not yet open to public), my system simply doesn't complete the update properly. I have even tried opening my settings.php to allow for free access to no avail. I have run the standard procedure on my test server and it updates correctly with 6.10 so I doubt very much that I have misunderstood the process. This may be a problem with my host but my PHP configuration appears correct and I haven't been able to identify any other server side problems. Unfortunately, I am near ready to take my site from test to live and simply nuking my site database and starting from scratch with a clean install is hardly a viable maintenance procedure. I will seek support from Drupal.org however I was curious if others had this type of experience.


Newbie talking

geneatwell's picture


I am pre-production and still working on a local machine learning Drupal. You've helped a lot with other posts of yours that I have read but I am unclear about this statement you made above:

"You remove the old Drupal core files and copy in the new files, then... just run update.php"

Which are the core files? Everything under the directory that drupal currently resides in? To include the .htaccess file? Once the new files are created from the new tar ball I then just need to update the "sites" directory with my backup of that directory after copying the rest of the files from the tar ball created directory to my original drupal directory and then run update.php?

An ounce of "gouge" is worth a pound of knowledge.

victorkane's picture

This is actually a big topic, which is why I tried to keep my original answer to the point of just a generic update to a single module.

But your question is so good and people sooo need to have that answered, that I welcome it.

Rather than give you a step by step process, or a generic answer like "use a test site then transfer your test site to production", which is correct but begs the question of how to backup and copy sites, let's understand the basic idea.

Drupal when freshly installed starts out with a sites sub-directory under the Drupal document root ([DRUPAL]).
Your assets (pictures, files, videos, etc.) will accumulate either in [DRUPAL]/files or else [DRUPAL]/sites/default/files, or else [DRUPAL]/www.example.com/files, this latter in a multi-site install.

Then, let's assume you follow best practices in the course of your site building and maintenance and install, in a single site environment, all third party modules and themes to [DRUPAL]/sites/all/modules and [DRUPAL]/sites/all/themes.

Drupal core is everything else.

That's why it's all very well to talk about test sites, and indeed Aaron is absolutely right, you got to do updating on a test site before throwing in the monkey wrench on a production site; but this saves your behind in terms of sites/all/themes and sites/all/modules and the database (which is basically what you need to copy to copy a site).

But not core. At some point, after testing out everything on your test site, you are going to have to log in as user #1, wrap your robes tightly around you and blow the drupal core files out of the water: erase them all (except your own stuff in ./sites/all and ./files)!

Everything except:

.htaccess if you have edited it; otherwise blow it away also
robots.txt if you have customized it; otherwise blow it away also
in Drupal 5.x, obviously save your settings in [DRUPAL]/sites/default/settings.php (in Drupal 6.x you don't need to worry since the core install tarball has no settings.php, but rather a default.settings.php which you then copy to settings.php).

And then, after blowing away Drupal core, you replace it with the new files. This is necessary strictly speaking to make sure nothing is left behind from the last release.

Then still logged in as admin #1 you run update.php.

Now, this is why in my book, Leveraging Drupal ( http://www.amazon.com/Leveraging-Drupal-Getting-Your-Right/dp/0470410876... ) I choose to use the command line to install and then update Drupal releases using CVS. This is described in the Drupal handbook, but the fact of how easy and risk free (easily reversible) it is escapes most people at first glance.

For example, let's suppose I installed my initial clean Drupal install a few weeks ago by situating myself above document root, which let's assume is "public_html", and typing:

# cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal co -d public_html -r DRUPAL-6-9 drupal

From then on, during the entire life of the installation, all I need do (specifying the release so as not to update to Drupal HEAD) is the following, from within document root:

public_html # cvs update -dPr DRUPAL-6-10

Then (after backing up my database!) I run update.php . If I then read that people are having problems, or I experience inconvenience, I can just go back, by restoring the database and typing the following (no update.php, since the files will be in sync with the restored database):

public_html # cvs update -dPr DRUPAL-6-9

Victor Kane


geneatwell's picture

I am now successfully running 6.10. Thanks again for the education.

My procedure

Charles Oertel's picture

I run a multi-site installation. This means that I have several client sites in /var/www/drupal/sites/, and all the contributed modules and additional themes go into /var/www/drupal/sites/all

Obviously, I test the procedure every time on my development server - and then I follow the same procedure on the live server. This is how:

Upgrade Module

  1. Copy the old module directory to the /tmp directory so that you can copy it back if needed in a hurry
  2. Don't move or delete the old module files, because on a live site that will break it until the new module files are copied
  3. Untar the module tarball over the old files (that's all). Just overwrite the old files with the updated copies.
  4. Run update.php in your browser

Upgrade Drupal (e.g. 6.9 to 6.10)

My /var/www directory has /var/www/drupal-6.9/ in it, with a symlink pointing to it named 'drupal'. So that /var/www/drupal is effectively /var/www/drupal-6.9 (almost like a Windows shortcut but better).

  1. Untar the new drupal version into /var/www so that you have /var/www/drupal-6.10 alongside the old 6.9 directory and the symlink 'drupal' still pointing at the old directory
  2. Now copy the old drupal/sites/* directory into the drupal-6.10/sites/ directory, so that all your contributed modules, themes and client websites are copied into the new structure
  3. In one quick command, point the 'drupal' symlink to your updated directory: 'rm drupal;ln -s drupal-6.10 drupal'
  4. Run the update.php script to apply any changes to the core database files

With this technique, the old drupal is totally untouched on your server, and going back is a matter of relinking the drupal symlink to it. However, if you have run the update.php script, and it made database changes, you need to restore a backup of the old database.

Generally, if the process works on your development server, and you have taken pains to ensure the development environment is a close mirror of the live environment, the live update will work as well. One thing I do is dump all my live databases onto dev before I do the upgrade. That way, if it works in dev, I have a working version available to use for trouble-shooting if the live one croaks.

Charles Oertel

But what if...

victorkane's picture

The new version changes the name of a file, or consolidates two into one...


Then you can break your site with a function appearing twice in the same namespace (loaded in memory by Drupal as part of the same process)! It has happened to me.

I would suggest either using the drush module (also explained in my book :) ) or else making a bash script that does something like what you are saying real quick, except it renames a directory, copies in the new and erases the old, then you run update.php

However, you really should put your site in maintenance mode before updating stuff (shouldn't do it "live").

Victor Kane

There have been plenty of

aaron's picture

There have been plenty of times where NOT deleting the old module files has caused problems (including an old emfield update by yours truly that caused a WSOD in some circumstances if one of the old .inc files had not been deleted). It is good practice to always remove the old module files when updating.

You can get around this by using a CVS checkout of the module, or by using subversion (SVN) to maintain your directory tree. Then you can update on a production site and be certain the file system will match.

Aaron Winborn
Drupal Multimedia (book, in October!)
AaronWinborn.com (blog)
Advomatic (work)

Aaron Winborn
Drupal Multimedia (my book, available now!)

SVN + drush a sweet match!

victorkane's picture

This is an amazing combination. If you are versioning your sites directory with SVN (I recommend that), then you can install modules with drush:


$ drush pm install date --svnsync --svncommit --svnmessage="drush installed date"

Project date successfully installed (version 6.x-2.0-rc6).

Project committed to Subversion successfully

Then, you can do your updating and drush will remove old files for you and bring in the new automatically, and commit it for you to boot:

$ drush pm refresh
$ drush pm update --svnsync --svncommit

not to mention:

$ drush cache clear
$ drush sql dump > to/a/convenient/place/and/version/it/too

Once you get used to it, it's a dream come true! Check it out: http://drupal.org/project/drush

Victor Kane

Charles: Thanks for you

michaelbr's picture

Thanks for you suggestion, I'm using a setup similar to yours, but got the following problem:
1) in this configuration, the URL address will be showing sub1.mydomain.com/drupal/ instead of sub1.mydomain.com/, I'd like not showing the /drupal in my URL, how can I do that?
2) based on your statement 2, it seems to me that all your subdomain folder is located under the drupal-6.10/sites/, is it right? Sorry for this dumb question, I'm new to this.
3) with this configuration, when I enter sub1.mydomain.com, it'll show page does not existe, I'll need to enter sub1.mydomain.com/drupal in order to show my homepage, how can I fix it?

Thanks in advance for your suggestion/comment

Thanks in advance for your suggestion/comment

Multi-site configuration

Charles Oertel's picture

Hi Michael

My setup is the standard drupal multi-site configuration, documented here:

In your case, it looks like you have not set the apache virtual hosts correctly. When apache receives a request for domain sub1.mydomain.com, it must use as document root, the drupal directory (the one that contains the 'sites' subdirectory'.

So, with drupal installed in /var/www/drupal,
and the site in /var/www/drupal/sites/sub1.mydomain.com
and the apache virtualhost directive giving /var/www/drupal as the document root
your site should work.

The reason it works is that when drupal's index.php is called, it looks at the requested domain name and then finds the closest match in the /sites/ subdirectory.


Thanks Charles for your

michaelbr's picture

Thanks Charles for your quick reply, I'm afraid my main problem is that I'm on a shared host, therefore I don't have access to apache config files. I think I need to change the .htaccess file, but not very familiar with it, I'll do a little research/search to see how/where it can be done.

Thanks in advance for your suggestion/comment

Thanks in advance for your suggestion/comment

Shared accounts can work

Charles Oertel's picture

In your shared account, install Drupal in the main html directory. Then any URL you use will invoke drupal.

Now, just 'park' all the domains on that same directory, and put the settings and files for each of the domains in the sites subdirectory.

So, when accessing my1.mydomain.com, it invokes drupal, and drupal finds the settings to use in its sites/my1.mydomain.com

When I set it up like this on a shared account, the support people at the provider commented that I had found a way to circumvent their policy of allowing only one website per account!

If your provider gives you multiple databases, use a separate database for each site (in the sites/my1.mydomain.com/setting.php etc), but if not, just use different prefixes for each site in the one database.


My site updated..

prfctpatrn's picture

I have actually finally managed to get my server side install to update properly, however the combination of 6.10, Marinelli Giordani and FCKEditor is misbehaving. I can do without WSYWIG so uninstalling FCK fixed the problem. This Update process is going to age me prematurely.


Try the WYSIWYG API module

victorkane's picture

In the long run it will give you the most options.

See my write-up: http://awebfactory.com.ar/node/351

Victor Kane

Thanks you all for these

michaelbr's picture

Thanks you all for these invaluable comments, I'm not sure if I'm doing the right thing, in the beginning, I just upgraded my modules by doing exactly the same as most of you:
- deleted the old module folder (always on the devel site first, but still have the zipped copy stored in my backup dir)
- unzipped the new module into /sites/all/modules
- run update.php on the Admin > Site building > module page
but my trouble is when you run update.php, the default option for each modules is no update available, therefore when I run the update, it just showed 0 of 0 updates, is this correct? or should I choose the last one before the no update available for the modules I updated?

One additional questions: if I have 3 modules to update, can I run update.php after removing/installing all 3 or it's better to do it 1 at a time?

Thanks in advance for your suggestion/comment

Thanks in advance for your suggestion/comment

"but my trouble is when you

victorkane's picture

"but my trouble is when you run update.php, the default option for each modules is no update available, therefore when I run the update, it just showed 0 of 0 updates, is this correct? or should I choose the last one before the no update available for the modules I updated?"

That simply shows that no database changes were made; but you have a healthy updated system because all the update scripts were run.

"I have 3 modules to update, can I run update.php after removing/installing all 3 or it's better to do it 1 at a time?"
All 3 is usually fine. :)

Victor Kane


elle.santos's picture

Hi, I was able to update now. I just remove the backup of my forward module, i renamed to oldforward, in the sites\all\modules. And the new version was detected.

Confused about upgrading Drupal modules

alternata99's picture

I am a Drupal beginner and shall appreciate very much your help in making clear this point to me. Thanks in advance.

I wish I find somebody capable of writing a concise-accurate-detailed-dependable-chronological list of numerated steps to follow in upgrading Drupal 6 modules.

After reading this node, I'm more insecure than before about what exactly I have to do for upgrading Drupal modules.

  1. The above explanation of michaelbr make sense to me (Is it correct?) but victorkane wrote repeatedly "remove the old module code" instead of "remove the old module folder". Is there a difference? What is exactly the meaning of "the...module code"?

  2. Should I disactivate the old module before I remove its "code" or its "folder"?

To update a module

victorkane's picture
  1. Just to be clear: we are talking about module updating, not upgrading a Major Release of Drupal (4.7->5, 5->6, etc.).
  2. You should not disactivate the old module before doing away with the folder.
  3. No difference between removing module code and removing folder, removing folder is fine; then reinstall module code (I emphasize "code" so people won't go and uninstall the module inside Drupal; just talking about the files on the disk).

These days, with drush, you can do the following from your drupal document root on the command line:

$ drush pm-updatecode

Then login as admin and perform an update.php

That's what I do, anyway

Thanks, Señor Kane, for your

alternata99's picture

Thanks, Señor Kane, for your response.

I suppose that in point 3: "...so people won't go and uninstall the module inside Drupal..." you intend to mean disactivate . Isn't it?

update multisite & multi-db at once

totaltheme's picture

I have 50 drupal sites that have their own databases but share single code base (multi-site). So I only need to update the code once, but I have to manually run update.php 50 times to update the databases. Is there a script / module that able to update all drupal instance databases in multi-site installation at once? It looks possible from my perspective, just wonder if anyone has created the module so I don't need to reinvent the wheel. Thanks in advance.

TotalTheme - Free Drupal Themes

re: update multisite & multi-db at once

fending's picture

Take a look at Run Drush commands on all sites in multi-site install for a bash script. drush -- in particular the updatedb feature you're talking about -- doesn't current support running that on multisites at one time. there's another issue for that in Concurrently execute a single drush command on multiple sites.

As was stated earlier in the thread, and I think this pertains 50X here, you need to test every change across all 50 multisites before running this kind of thing in production. In theory, it's great. But a bit of a long rope.

Excellent! I heard about

totaltheme's picture

Excellent! I heard about Drush, seem it's a good time to peek the code. Thank you Brian for sharing this. My problem is 90% resolved.

TotalTheme - Free Drupal Themes

Updating Drupal Modules with a New Twist

momo18's picture

OK! I'm in the confused camp. It's still related to updating modules, but with a slight twist. But let's start with some background first.

I had my multi-language technical writing/website development site at http://www.itwrite.com which supports multiple languages. I wanted to upgrade the live 6.x site to the current 6.17 version and add some theming functionality but first I wanted to make the changes locally on my test machine, not on the live server. I started by creating a fresh 6.17 site and then I downloaded and installed, and enabled all the required modules and language files into the new site through Drush. (I am using Eclipse PDT bye the way.) I dropped the 6.17 database and then I imported the backed up database data and I copied all the live theme files etc, to my test environment.

So far so good.

Next I ran the drush updatedb command. That I guess was supposed to make everything from 6.x to 6.17 compatible. But that generated an error with an error message saying that a column on one of the tables in one of the language modules was missing. (It so happens that it was the i18nstrings module, belonging to part of the greater i18n multi-language module family.)

So, I checked to see which modules were enabled and of course the language modules were all enabled - especially the i18nstrings module creating the problem. So I went back and checked the i18nstrings module and in the i18nstrings module directory there was indeed an i18nstrings.install file ready to be executed with the appropriate database schema changes I expected to see.

Now the problem. The i18nstrings module has a dependency on other modules and it cannot be disabled unless I disable the entire internationalization module. If I disable the internationalization module I'm likely to blow away tons of valuable database tables higher up stream and more, so I don't want to do that. Second, I expect that if I execute the i18nstrings.install module as a standalone it might possibly fix the problem. But how do I do that? Is it OK, to execute one .install file that's part of a bigger module.

Hope this is clear enough. There seems to be enough information about updating individual modules, but not when the live data is being imported and then you subsequently need to update the old database schema structure to conform to the new database schema that's expected by the new modules.

If anybody could present some practical steps on to how achieve this, please do. I guess I could find the database schema alter statements and execute them manually, but that I would think defeats the purpose of having an install script and doing things the right way.

Should I instead have done the following. Dropped the 6.17 database and imported the old 6.x database, after which I installed the additional modules (including internationalization module) - so that the individual .install module scripts executed, then run update.php, not the other way around?

I've seen this problem elsewhere, so I know I'm not alone. Hope this is clear enough.

Technical Writing Services

Victor, are you still using

Diegen's picture

Victor, are you still using SVN or have you switched to Git ? Which in your opinion is better ?

Git is a major step forward

victorkane's picture

And even though I postponed it for a long time, I have definitively switched to Git.

SVN integration certainly helps the transition, but it is best to just make the switch.

I use GitHub as a private repository (it allows you to use SVN with Git repositories, but you should make the switch).

Best resource on Git is free

victorkane's picture

Chacon's ProGit book is online free: http://progit.org/book/ Best book on Git.

github has put up a Git reference/tutorial site: http://gitref.org (http://bit.ly/96KZB9)

On your blog you mentioned a transition to GIT

Diegen's picture

I visited your site recently, which is filled with useful information. I am sure I read a article on transitioning to GIT, but now I cannot find it. Am I imagining this or could you send me a link ?

Only a very old article

victorkane's picture

http://awebfactory.com.ar/node/173 (cg is no longer used,

I think you are reading my mind... I need to update that with a new article that shoes Git 1.7 and tailoring to Drupal!

And this one


ronherren's picture


Modules refuse to update

mike3945's picture

Local newspaper site with lots of modules. About a year on drupal. Doesn't feel like a day over three years. Have dug myself out of a couple of near catastrophic disasters. Not great at coding. I'm fully prepared for this to be a stupid question.
I attempt to update given modules and nothing happens...the old version remains intact...even if I rename the old folder ".old" in case the update causes an error. But otherwise after updating a module I get no error just the same old version.
With 3 or 4 modules constantly wanting updates and order of dependency seldom being indicated in the txt file, I've wasted a lot of time. It's against my religion to use "dev" modules. 15 or 20 other modules are up to date.
For example;
Can't get jquery to go from 1.3 to 1.4; imageapi to go from 1.8 to 1.9; the latest ckeditor won't stick.
What did I miss and whats my next MO? Is there a utility?

Mike Burman


Michelle's picture

You can't just rename a directory. If you want a backup, put it someplace outside of Drupal's hierarchy. Then delete the directory, untar the new one in its place, and run update.php.


If your update.php script

decibel.places's picture

If your update.php script fires too often your IP may get blocked by Drupal infrastructure requiring intervention

I'm not at all sure this is your problem, but if all else fails see http://drupal.org/node/579376#comment-2101166

If you have tried everything else - file an issue with the Drupal Infrastructure team, be sure to include your site's domain and/or IP


My IP was banned on one node, so some update information was displayed and others failed - and different info was displayed each time - now it is updating fine after the block was removed.

TIP: Drush will automatically back up your modules (-: http://drupal.org/project/drush

Thanks bundles for the "to

mike3945's picture

Thanks bundles for the "to the point" answer.

It hard to stay "on top" of the updates when they come two and three a day. And I'm not being lazy when it often take twenty or more minutes to make one update which may or may not stick.

Any working shortcut I discover is appreciated. Most often renaming an old version file saved time and saved heartache when the update didn't stick for whatever reason.

Is someone suggesting that core recognizes a renamed module and loads it anyway? Some of the modules are very large (in case of an error...quick return to normal) and some are in convoluted paths.

However the statistical probability of finding the correct update combination with a hundred modules is wearing. Is there a map or a list in order of prerequisite dependency?

I have learned the hard way to do one update at a time. Therefore, I necessarily must go into update four or five times at a sitting IF the updates stick. If I try to keep updates to one a day, that assumes that I have picked the correct order of the update which is lately just a lucky guess.

Otherwise I love (need) the functionality, I just want to solve the problems.

Am I right, that by contacting Drupal Infrastructure team maybe there isn't a ready solution? I might have a few redundant modules but not many.

Thanks again, MB

Mike, have you looked into

wernerglinka's picture

have you looked into using drush? http://drupal.org/project/drush It is a command line tool but it changed my life. Updates are now a matter of minutes.


Michelle's picture

It hard to stay "on top" of the updates when they come two and three a day.

Security releases only come out on Wednesdays and usually not every Wednesday. Unless there's a must have update to a module in the mean time, I just wait until there's a security release that affects my site and then do all the module updating then. So generally not more than once or twice a month.

Is someone suggesting that core recognizes a renamed module and loads it anyway?

If you rename the directory to module.backup or whatever, Drupal will still find the .module file inside it. If you rename the .module file, I'm not sure if it would recognize it as the .info file will have different information. But it's not worth risking the confusion. Just backup outside of the Drupal hierarchy.



geneatwell's picture

Be aware that some shared accounts will not allow the use of Drush. Midphase is one of those and while they allowed Drush usage for a while, they have since denied usage.

Thanks Michelle, Drush looks

mike3945's picture

Thanks Michelle,

Drush looks looks relatively unrecoverable in the event of a keying error (like winDOS??) which I can imagine making while I figure it out. But I'll start studying.

So it recognizes renamed "backup" folders but it won't "discover" jquery_ui or ckeditor updates no matter where (subfolders) I put them. I have to go back to lightbox 10 because it just doesn't see LBX11.

I'm sure these are some hierarchy/dependency problem but I just can't find them. Has anybody done one of these sheets?

With a hundred modules it feels like it's more often but in any case in one sitting I use the update 4 or 5 times just trying to get the aforementioned modules to stick. If that causes an IP problem too, that's just great.

Really,really appreciate the answers
Mike B


Michelle's picture

Take a look in the system table and see what path it has for them. Make sure you don't have any other copies floating around anywhere.


Is this the sql DB on the

mike3945's picture

Is this the sql DB on the server?

Updates report not reflecting the update

solomojo's picture

After completing the steps to update a module, when I go to /admin/reports/updates it still lists the previous version of the module and that it needs to be updated.

For example I was using CAPTCHA 6.x-2.2 so I updated to 6.x-2.3 by:

  1. Setting the Site Maintenance Status to "off-line"

  2. Deleting the sites/all/modules/captcha folder
    cd sites/all/modules
    rm -rf captcha

  3. Unpacking the updated module onto the server.
    cd sites/all/modules
    wget http://ftp.drupal.org/files/projects/captcha-6.x-2.3.tar.gz
    tar zxvf captcha-6.x-2.3.tar.gz

  4. Running www.mysite.com/update.php
    NOTE: In the select versions it said "No updates available" under captcha module. I ran the update.php anyway.

  5. Setting the Site Maintenance Status to "on-line"

I did this with several different modules all with the same result. I also checked each updated module's .info file for the version number and it shows the new version number. I also tried clearing the site cache on the performance page.

I am using Drupal 6.19 with a multisite setup. Each site has its own database but they all use the same Drupal Core.

Any helpful info on getting the updated module versions to show on the Available Updates list would be a huge help.

I was running update.php from https

solomojo's picture

I tried the process again and made sure that I was not using https and that seems to have solved the problem. I have my admin section on SSL so when I clicked the link to go to update.php it stayed in https. I removed the folders... unpacked the updates again... and ran the update.php making sure that it was on my http domain and voila it worked.

Such a simple question

LJEsposito's picture

Such a complex response - Welcome to Drupal!

Larry Esposito

:) My sentiments exactly!

strands's picture


My sentiments exactly!

Multiple Moldule Updates?

ja09's picture


I'm wondering if it's best practice to update modules one at a time/run update.php per module...

Or can I just update all modules, then run update.php for everything?.. updating between 2-6 modules at once. Thanks!

If I have many to do, I do

greta_drupal's picture

If I have many to do, I do them in batches -- 3 or 4 at a time. Run update.php after each batch, and make a (Backup & Migrate module) backup after each update run. I save the more problematic modules (e.g., Date, Calendar; Image modules) for last -- doing those in individual batches too, in case I need to roll back the database to previous batch.

If you only have a few modules, and don't anticipate problems, make a db backup then install them all at once. One update.php.

Always first delete the old folder, then unzip the new update. (Personally, I don't bother to uninstall the modules first -- quite a PITA and then I have to remember exactly which components of the modules I had enabled.)

This is how I roll.

Don't forget the drush alternative

revagomes's picture

If you are familiar with drush you can run the "drush sql-dump" command to make the database backup and then run the "drush up" for update the modules.

Drush already make a bkp of the old module by default and it's really fast to make an update for a bunch of modules as well.

For more information about drush visit the drush project page http://drupal.org/project/drush


Keep in mind that we are whom will change the world!
revagomes.com.br is powered by Drupal.

Tool to Install or update Drupal 6 or 7 modules or themes

cslavoie's picture

If it can be of use to anyone, I have written a small tool to batch update all the modules in a directory. Let me know what you think of it.


Not always on Drupal specifically, but you may find something interesting: http://blog.lavoie.sl/

Updating from 6.x.1.11 to 6.x.1.14 acceptable?

preper's picture


My nodewords module is version 6.x.1.11. I know that there are some data losses and bugs in some versions?

Can I update my module form 6.x-1.11 to 6.x.1.14 normally or should I make some extra things not to lose any data.

Drupal Dojo

Group organizers

Group events

Add to calendar

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: