Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
An error occurred. http:///update.php?id=1&op=do
Fatal error: Call to undefined function _system_update_utf8() in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\content\sites\all\modules\signup\signup.install on line 189
Comments
Comment #1
chasz commentedThe update process was aborted prematurely while running update #1 in signup.module. All errors have been logged. You may need to check the watchdog database table manually.
Comment #2
dwwUhh, you shouldn't be running signup_update_1() with the D6 version. ;) I should probably remove that from the .install file. The only ways this could happen are:
A) You manually selected update #1 when you shouldn't have.
B) You've got a site with a DB schema that's older than February 2006 (probably 4.6.x) and you're now trying to upgrade directly to D6. That's definitely not going to work, either from core, nor signup. ;) If your DB schema is really that old, you need to upgrade in a few steps (e.g. to the latest 4.7.x, and then the latest 5.x) before you can upgrade to D6.
Comment #3
chasz commentederhm, i started with drupal 6.4 updated to 6.8
this is the first signup update that gave me that error, has this module just jumped a revision? rev1 -> 2
Comment #4
dwwsomething got screwed up in your DB then, since if you had installed signup.module for core version 6.4, it should have set the {system}.schema_version value for signup to something like 6000 or so (depending on exactly what version of signup you started with. When you upgraded to another version, it should have started from update 6000 and gone up, not gone back to 1.
Ohhhh... hrm, I just noticed you set the version of this issue as 6.x-2.x-dev. That's the problem. ;) This release isn't supported, since I decided to backport the changes from HEAD into the DRUPAL-6--1 branch and put the 6.x-2.* series on hold for now. I guess I never fully documented this on the release nodes before, but if you were using 6.x-2.x-dev (which already had a warning about not deploying it except on test sites), your DB is in an inconsistent state, which is why update.php thought you wanted to run signup_update_1() again. :( I just added a note to the signup 6.x-2.x-dev release node about this, including the DB query you can run to repair your {system} table once you downgrade to 6.x-1.x-dev.
Sorry about the hassle, but that's life with -dev snapshot releases. ;)
All that said, I guess I should still rip out the really ancient DB updates from the D6 version of signup.install since they're going to fail, anyway.
Comment #5
chasz commentedok i still cant update it....the id = 3 this time
edit: you might need
UPDATE {system} SET schema_version = 6002 WHERE name = 'signup' AND schema_version NOT 6002;
edit2:
user warning: Lock wait timeout exceeded; try restarting transaction query: UPDATE system SET info = 'a:9:{s:4:\"name\";s:6:\"Signup\";s:11:\"description\";s:55:\"Allow users to sign up for content (especially events).\";s:4:\"core\";s:3:\"6.x\";s:7:\"version\";s:11:\"6.x-1.0-rc3\";s:7:\"project\";s:6:\"signup\";s:9:\"datestamp\";s:10:\"1229806262\";s:12:\"dependencies\";a:0:{}s:10:\"dependents\";a:0:{}s:3:\"php\";s:5:\"4.3.5\";}', name = 'signup', filename = 'sites/all/modules/signup/signup.module', bootstrap = 0 WHERE filename = 'sites/all/modules/signup/signup.module' in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\content\includes\module.inc on line 141.
Comment #6
dwwThe problem is that once you ran update.php and started from update 1, the DB was even further confused. I recommend you start over from your DB backup from before when you ran update.php in the first place. I'm really not supporting the 6.x-2.x-dev series at all. This is as much effort as I care to spend on it.
Comment #7
chasz commentedomg LOL
does it affect ALL drupal or can i just delete the entry for signup in system?
edit i am trying to get it back to revision 1 here
Comment #8
dww@chasz: FYI: Please only edit your issue replies to fix typos. If you have more to say, please add a new comment. Thanks.
In terms of the problems reported here:
A) I've removed signup_update_1() and signup_update_2(), both of which were from the 4.7.x version of the module. The practice in core is to only keep the DB updates from the current and previous versions of core. I committed this change to HEAD and DRUPAL-6--1.
B) 6.x-2.x-dev is unsupported. No one should have installed it, especially not on anything other than a test site. (I shouldn't have even created it yet, honestly). As a -dev snapshot, with code and schema in flux, I did something that (should have) made my life easier in the long run by moving from schema changes from HEAD into the DRUPAL-6--1 branch and removing those updates from HEAD. Unlucky people who were running my -dev snapshot at the time got a DB in an inconsistent state. Thanks to this issue, I've added a warning to the release node about this, but that's as far as I care to go. This is -dev after all -- use at your own risk. As the person who wrote the release system for Drupal I take my release management fairly seriously. :) If you stick to my official releases, you're almost always going to be in good shape. If you use my -dev snapshots, you have to act like a developer who knows what you're doing, since that's the target audience.
Cheers,
-Derek
Comment #9
chasz commentedIF I DEleted the entry in the {system}, how would it affect the consistency of the DB?
if i then ran update again, it will just update to the latest revsion and i should be alright?
Comment #10
chasz commentedok, i unistalled the sign and now re-activated it the rev1rc3 and the whole modules page freaks out......i wonder if it having troubles with the chrysalis theme?
Comment #11
chasz commentedok i cant reinstall sign, UC_auction and quicktabs, and all 3 insert new tables into the DB, when i try to return to the modules page i get DB errors
Comment #12
chasz commented* user warning: Lock wait timeout exceeded; try restarting transaction query: UPDATE system SET schema_version = 6048 WHERE name = 'system' in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\content\includes\install.inc on line 99.
* user warning: Lock wait timeout exceeded; try restarting transaction query: UPDATE system SET schema_version = 6100 WHERE name = 'vertical_tabs' in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\content\includes\install.inc on line 99.
* user warning: Lock wait timeout exceeded; try restarting transaction query: UPDATE system SET schema_version = 6204 WHERE name = 'webform' in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\content\includes\install.inc on line 99.
* user warning: Lock wait timeout exceeded; try restarting transaction query: UPDATE system SET schema_version = 6003 WHERE name = 'comment' in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\content\includes\install.inc on line 99.
* user warning: Lock wait timeout exceeded; try restarting transaction query: UPDATE system SET schema_version = 6005 WHERE name = 'locale' in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\content\includes\install.inc on line 99.
how do i solve this?
Comment #13
dwwThis is a bug report about signup_update_1() still existing in a version of signup.install which is calling API functions which don't exist anymore. That bug has been fixed. I also fixed the "bug" of documenting how to avoid running update_1 accidentally while you're using the unsupported 6.x-2.x-dev version. If you want more support for your particular problems, please meet me over at your support request: #351178: the module is NOW unselectable. Let's leave this issue closed, thanks.