Page MenuHomePhabricator

Update script is failing midway when updating from 1.18 or earlier to 1.23 due to unknown 'user_password_expires' column
Closed, ResolvedPublic

Description

Author: duongxvu

Description:
For context, we are in the midst of upgrading our MediaWiki installation from 1.17 to 1.23wmf19. We've tried running the update script from the command line (as well as using the web updater) but keep running into the same error message copy-pasted below:

...batch conversion of user_options: Notice: Undefined property: stdClass::$user_password_expires in [REDACTED]/var/www/html/wiki/includes/User.php on line 1227
A database query error has occurred.
Query: UPDATE mw_user SET user_name = '[REDACTED]',user_password = ':[REDACTED]',user_newpassword = ':[REDACTED]',user_newpass_time = '[REDACTED]',user_real_name = '[REDACTED]',user_email = '[REDACTED]',user_email_authenticated = '[REDACTED]',user_touched = '[REDACTED]',user_token = '[REDACTED]',user_email_token = '[REDACTED]',user_email_token_expires = '[REDACTED]',user_password_expires = NULL WHERE user_id = '1'
Function: User::saveSettings
Error: 1054 Unknown column 'user_password_expires' in 'field list' ([REDACTED IP ADDRESS])


Version: 1.23rc
Severity: blocker

Details

Reference
bz63677

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 3:24 AM
bzimport set Reference to bz63677.

https://www.mediawiki.org/wiki/Release_notes/1.23 says:
A user_password_expires column has been added to the user table. The User object expects this column to exist. Use update.php to create this new field.

If update.php does not work as expected, please attach its call and output.

Also, do you intentionally run an unstable development version of MediaWiki?

The ConvertUserOptions script is running on the updater.
The script was added there by version 1.19.
So there is a updater problem, when coming from a pre1.19 version to a (at the moment unreleased) version 1.23.
One way to fix this is updating to a version between 1.19 and 1.22 first. Better is fixing the updater. So setting the target milestone to 1.23.

Column was added by gerrit 92037.

So this is basically about moving "array( 'addField', 'user', 'user_password_expires', 'patch-user_password_expire.sql' )" before "array( 'doMigrateUserOptions' )" in the updater?

Sounds like a trivial fix. I'd like to get it done this week.

Change 133411 had a related patch set uploaded by Withoutaname:
Add user_password_expires before running ConvertUserOptions.php

https://gerrit.wikimedia.org/r/133411

(In reply to Mark A. Hershberger from comment #4)

Sounds like a trivial fix. I'd like to get it done this week.

hexmode: 3 liner patch for includes/installer/DatabaseUpdater.php available for review.

Tests are currently failing on this one. We'll have to ship with it and fix it in 1.23.1.

Andre, please add a milestone to bugzilla for 1.23.1.

Change 136339 had a related patch set uploaded by PleaseStand:
Make convertUserOptions.php more self-contained

https://gerrit.wikimedia.org/r/136339

I think the way PleaseStand's patch handles this is better than moving the order of the database updates around. If someone can verify the update script works for old wikis, I think we can merge it for 1.23.0.

The update script works for me both in current REL1_23 and with PleaseStand's patch. In other words, I cannot reproduce the bug. Here's what I did:

  • checked out REL1_17
  • installed MW
  • Modified some user settings
  • switched to REL1_23
  • ran update.php

It worked in both cases. There was no user_password_expires before, and now there is.

(In reply to Markus Glaser from comment #10)

The update script works for me both in current REL1_23 and with
PleaseStand's patch. In other words, I cannot reproduce the bug. Here's what
I did:

  • checked out REL1_17
  • installed MW
  • Modified some user settings

The bug does exist.

Only 1.15 and earlier would store user preferences in the user_options column. It was 1.16 in which the user_properties table was added; when User::saveSettings() is called in 1.16 - 1.18, user_options is set to the empty string.

The convertUserOptions.php script has a "user_options != ''" condition in the SELECT statement. So no rows would be returned, and the script would not have called User::saveSettings() in your case.

Thanks PleaseStand. I was able to reproduce the bug with MW1_15 and can confirm your fix resolves the bug.

Change 136339 merged by jenkins-bot:
Make convertUserOptions.php more self-contained

https://gerrit.wikimedia.org/r/136339

Change 136938 had a related patch set uploaded by Bartosz Dziewoński:
Make convertUserOptions.php more self-contained

https://gerrit.wikimedia.org/r/136938

Change 136938 merged by jenkins-bot:
Make convertUserOptions.php more self-contained

https://gerrit.wikimedia.org/r/136938

Withoutaname: https://gerrit.wikimedia.org/r/#/c/133411/ seems to need rebasing? (That's the only open patch left for this ticket)

Andre, I think this bug was fixed by https://gerrit.wikimedia.org/r/#/c/136938/ in a better way than Withoutaname's patch.

Since Kevin's patch was merged, I think this bug can be closed?

Change 133411 abandoned by Bartosz Dziewoński:
Updater: Create user_password_expires before doMigrateUserOptions

Reason:
Superseded by https://gerrit.wikimedia.org/r/136339.

https://gerrit.wikimedia.org/r/133411