Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Fatal error: Call to undefined function drupal_load_updates()
Lately I've been experiencing this error whenever I try to update modules.
It occurs on Drupal 5.x
# drush -r /var/www/drupal -l http://www.site.name update
Update information last refreshed: Sat, 10/03/2009 - 2:00am
Update status information on all installed and enabled Drupal modules:
Name Installed version Proposed version Status
CAPTCHA 5.x-3.2 5.x-3.2 OK
Drupal 5.20 5.20 OK
Event 5.x-1.0 5.x-1.0 OK
GMap Module 5.x-1.1-rc1 5.x-1.1-rc1 OK
IMCE 5.x-1.2 5.x-1.2 OK
Simplenews 5.x-1.5 5.x-1.5 OK
TinyMCE 5.x-1.9 5.x-1.9 OK
Update Status 5.x-2.3 5.x-2.3 OK
XML sitemap 5.x-1.6 5.x-1.7 SECURITY UPDATE available
Code updates will be made to the following projects:
XML sitemap [xmlsitemap-5.x-1.7]
Note: Updated modules can potentially break your site. It's not recommended to update production sites without prior testing.
Note: A backup of your package will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue? (y/n): y
Project xmlsitemap was updated successfully. Installed version is now 5.x-1.7.
Backups were saved into the directory [ok]
/var/www/drupal/backup/modules/20091003155042.
Cache cleared.
Fatal error: Call to undefined function drupal_load_updates() in /opt/drush/commands/pm/pm.drush.inc on line 503
Drush command could not be completed. [error]
and a similar error occurs on Drupal 6.x
# drush -r /var/www/drupal_devel -l http://devel.site.name update
Refreshing update status information ...
Done.
Update information last refreshed: Tue, 10/06/2009 - 17:20
Update status information on all installed and enabled Drupal modules:
Name Installed version Proposed version Status
Advanced help 6.x-1.2 6.x-1.2 Up to date
Drupal 6.14 6.14 Up to date
Mailman Manager 6.x-2.3 6.x-2.3 Up to date
CAPTCHA Pack 6.x-1.0-beta3 6.x-1.0-beta3 Up to date
Messaging 6.x-2.1 6.x-2.1 Up to date
Notifications 6.x-2.1 6.x-2.1 Up to date
Organic groups 6.x-1.3 6.x-1.4 SECURITY UPDATE
available
Token 6.x-1.12 6.x-1.12 Up to date
User mailman 6.x-2.0 6.x-2.1 Update available
register
Views 6.x-2.6 6.x-2.6 Up to date
Vote Up/Down 6.x-1.0-beta6 6.x-1.0-beta6 Up to date
Voting API 6.x-2.3 6.x-2.3 Up to date
Wysiwyg 6.x-2.0 6.x-2.0 Up to date
XMPP Framework 6.x-2.0 6.x-2.1 Update available
Code updates will be made to the following projects:
Organic groups [og-6.x-1.4], User mailman register [user_mailman_register-6.x-2.1], XMPP Framework [xmppframework-6.x-2.1]
Note: Updated modules can potentially break your site. It's not recommended to update production sites without prior testing.
Note: A backup of your package will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue? (y/n): y
Project og was updated successfully. Installed version is now 6.x-1.4.
Project user_mailman_register was updated successfully. Installed version is now 6.x-2.1.
Project xmppframework was updated successfully. Installed version is now 6.x-2.1.
Backups were saved into the directory [ok]
/var/www/drupal_devel/backup/modules/20091006172048.
Fatal error: require_once(): Failed opening required './sites/all/modules/views/includes/view.inc' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/drupal_devel/sites/all/modules/views/views.module on line 512
Drush command could not be completed. [error]
After much experimentation, I found that the errors do not occur when CVS is disabled in .drushrc.php, but when CVS is enabled I get this:
# drush -d -r /var/www/drupal_test -l http://mytest.site.name update
Drush bootstrap phase : _drush_bootstrap_drupal_root() [0.024 sec] [bootstrap]
Initialized Drupal 5.19 root directory at /var/www/drupal_test [0.034 sec] [notice]
Drush bootstrap phase : _drush_bootstrap_drupal_site() [0.036 sec] [bootstrap]
Initialized Drupal site mytest.site.name at sites/mytest.site.name [0.059 [notice]
sec]
Drush bootstrap phase : _drush_bootstrap_drupal_configuration() [0.061 sec] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_database() [0.066 sec] [bootstrap]
Successfully connected to the Drupal database. [0.066 sec] [bootstrap]
Drush bootstrap phase : _drush_bootstrap_drupal_full() [0.071 sec] [bootstrap]
Including non-version specific file : /opt/drush/commands/core/drupal/environment.inc [0.207 [notice]
sec]
Drush bootstrap phase : _drush_bootstrap_drupal_login() [0.278 sec] [bootstrap]
Found command: update [0.281 sec] [bootstrap]
Including /opt/drush/commands/pm/updatecode.inc [0.281 sec] [bootstrap]
Including version specific file : /opt/drush/commands/pm/update_info/drupal_5.inc [0.283 [notice]
sec]
Update information last refreshed: Wed, 10/07/2009 - 12:12pm
Update status information on all installed and enabled Drupal modules:
Name Installed version Proposed version Status
CAPTCHA 5.x-3.2 5.x-3.2 OK
Drupal 5.19 5.20 SECURITY UPDATE available
Event 5.x-1.0 5.x-1.0 OK
GMap Module 5.x-1.1-rc1 5.x-1.1-rc1 OK
IMCE 5.x-1.2 5.x-1.2 OK
Simplenews 5.x-1.5 5.x-1.5 OK
TinyMCE 5.x-1.9 5.x-1.9 OK
Update Status 5.x-2.3 5.x-2.3 OK
XML sitemap 5.x-1.6 5.x-1.7 SECURITY UPDATE available
NOTE: A code update for the Drupal core is available.
Drupal itself can't yet be updated by this tool. Please update Drupal manually.
Including non-version specific file : /opt/drush/commands/pm/package_handler/cvs.inc [0.322 [notice]
sec]
Including non-version specific file : /opt/drush/commands/pm/version_control/svn.inc [0.322 [notice]
sec]
Code updates will be made to the following projects:
XML sitemap [xmlsitemap-5.x-1.7]
Note: Updated modules can potentially break your site. It's not recommended to update production sites without prior testing.
Note: A backup of your package will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue? (y/n): y
Starting to update XML sitemap code ... [14.348 sec] [notice]
Calling mkdir(/var/www/drupal_test/backup, 511)
Calling mkdir(/var/www/drupal_test/backup/modules, 511)
Calling mkdir(/var/www/drupal_test/backup/modules/20091007121547, 511)
Calling rename(/var/www/drupal_test/sites/all/modules/xmlsitemap, /var/www/drupal_test/backup/modules/20091007121547/xmlsitemap)
Calling chdir(/var/www/drupal_test/sites/all/modules/)
Updating project xmlsitemap ... [14.349 sec] [notice]
[14.349 sec] [notice]
[14.349 sec] [notice]
Executing: cvs -z6 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal-contrib checkout -d xmlsitemap -r DRUPAL-5--1-7 contributions/modules/xmlsitemap
cvs checkout: Updating xmlsitemap
U xmlsitemap/CHANGELOG.txt
[snip...]
cvs checkout: Updating xmlsitemap/xsl
Updating out xmlsitemap was successful. [19.599 sec] [notice]
Project xmlsitemap was updated successfully. Installed version is now 5.x-1.7.
Backups were saved into the directory /var/www/drupal_test/backup/modules/20091007121547. [ok]
[19.599 sec]
Cache cleared.
Fatal error: Call to undefined function drupal_load_updates() in /opt/drush/commands/pm/pm.drush.inc on line 507
Drush command could not be completed. [19.603 sec] [error]
It appears to me as if the CVS module is changing the current working directory so that includes that default to the drupal root will fail.
After the module has been installed with the CVS option, I must manually run update.php to complete the database updates, but even then, something is not right. In the Drupal admin modules page, the version number of modules installed by CVS does not appear, and the modules are not listed on the Available Updates page. For now, I'm disabling the CVS option while using the HEAD version of Drush.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | drush-598402-cvs.patch | 1.69 KB | dude4linux |
Comments
Comment #1
dude4linux commentedCreated a patch to save and restore the current working directory (cwd) in cvs.inc.
This appears to have eliminated the missing file errors downstream, but the missing module version information in the admin pages remains. There must be an additional difference in the way modules are installed by CVS vs the default wget.
Comment #2
moshe weitzman commentedyou need cvs deploy module to get those version numbers when you use cvs checkouts ... can anyone confirm that this patch fixes the bug. i am not using cvs checkouts anymore.
Comment #3
dman commentedI really want to keep using CVS checkouts, and have method set as CVS by default in all my dev locations but I've not encountered this error myself yet.
This patch sticks a wrapper around the problem, which sorta makes sense, but I think it would be tidier to do it deeper and closer to the action where the cvs execution causes the chdir to happen (if it does - it doesn't for me)
I'll see what's changed in the updates, I guess, but if I can't replicate, I can't test.
Comment #4
moshe weitzman commentedComment #5
dude4linux commentedMoshe is correct in pointing out that the CVS Deploy module is required to use the drush CVS option. Since I had never tried to use CVS before, I was unaware of the CVS Deploy module. The CVS Deploy module's page states
"CVS deploy is also required if you wish to use the incredibly helpful drush package manager, which handles installation and updates of Drupal projects via a simple command-line interface."but I could find no mention of the requirement in the Drush documentation.The issue could be dealt with by adding a warning when the CVS option is used without having the CVS Deploy module installed, or by simply adding a note in the Drush documentation that you need to install the CVS Deploy module before using the Drush CVS option.
Comment #6
intuited commentedIs there any circumstance under which
drush updatewill update a CVS-versioned module to the "official" version? I've been keeping patched modules under CVS version control, and it looks like drush updated some of them to mainline. eg the .info file shows drupal.org versioning information. It's possible that I had cvs_deploy enabled at that point in time as I was experimenting with it briefly but don't normally use it. However even if it were enabled I wouldn't expect something like that to happen.Alternatively, is there a better way to hold back packages from being updated?
Comment #7
dman commentedUpdate will use whichever 'package-handler' you tell it (or have settings) to use at the time. It does not remember what you used to put the module there last time.
You can use the update (or at least the dl) to overwrite your tarball copy with a cvs checkout and vice versa.
If you are wanting to maintain only CVS copies (I do too) then you just ensure that your package-handler=cvs for that site or when you use drush.
Your patched files have been copied to {drupaldir}/backup if you want them back.
Comment #8
intuited commented@dman: Thanks, though I think I'm more confused now. I've moved my questions to a new topic: #695646: Best way to hold back packages from being updated to help keep this thread on track.
Comment #9
moshe weitzman commentedthis is confusing. please start new (clearer) issue if needed.