Last modified: 2011-11-13 20:38:50 UTC
Confirm Account works for request account and review, but when actually hitting the send button to confirm, it reports: „User::createNew“. Database error „1054: Unknown column 'user_options' in 'field list' (localhost)“. Tested with MediaWiki 1.18.0beta1 (r102635) and confirm user accounts in the following versions: FROM 1.18: Confirm user accounts (r102635) FROM trunk (sic!): Confirm user accounts (r98122) (this was working so far, whereas the version distributed with 1.18 itself was not working for several months now) FROM trunk (sic!): Confirm user accounts (r102861) - newest of today. The error occurred only after updating mediawiki 1.18alpha (r100281) to 1.18.0beta1 (r102635).
related to Bug 31204 ?
user_options is still part of the 1.18 schema, so createNew() should not give that error unless you upgraded and then downgraded. Where exactly did you get these MediaWiki versions?
From SVN, using svn update. We only updated within the 1.18 branch (1.18alpha r100281 to 1.18.0beta1 r102635 and now back). However, two extensions (Semantic Forms and Confirm Account) had to be used from trunk because the 1.18 versions don't work. These worked fine with r98122, but in fact these were accidentally updated to trunk 1.19 r102635 for a brief time and later reverted (only these two extensions, not mediawiki core). Update.php was, however, run while Confirm Account was in r102635. Documented: http://biowikifarm.net/meta/Software_Maintenance#2011-11-12 and before. Your comment implies that this means something bad - can you suggest a way to return this to working? Update.php was run after restoring the correct versions.
You must have run the trunk/ update.php or something. I don't see how else user_options could have been removed otherwise. You will have to run "ALTER TABLE /* prefix */user ADD COLUMN user_options BLOB NOT NULL;" manually. Running 1.18 update.php will not reverse the changes later MediaWiki versions made. Just to be clear, by "branch" you mean /mediawiki/branches/REL1_18/, right?
Many thanks for the help! Manually adding the field back did work. > Just to be clear, by "branch" you mean /mediawiki/branches/REL1_18/, right? yes. And phase3 was never in 1.19 for these wikis. HOWEVER: we ARE running a wiki under 1.19svn for testing purposes and we use shared user tables. Update.php was executed for this testwiki. Could it be that 1.19 update.php modifies the shared user table in a different wiki, even though this wiki is in 1.18? If yes: would that be unavoidable, or should the code test if shared tables are not native? That is: should I write a bug report on this?
Since the situation means that in the future it will be impossible for a wikifarm with a shared user base to keep some "legacy" wiki on 1.18 or earlier, while updating the central user management wiki to 1.19: would it be possible to remove the dependency from the field "user_options" already in the 1.18 code, before 1.18 is finally released? It would not matter if many extensions use the old option and compatibility is impossible anyways. However, Confirm Account was the only code element that we use that expected this field to be present, so I think it might be worth it.
(In reply to comment #6) > Since the situation means that in the future it will be impossible for a > wikifarm with a shared user base to keep some "legacy" wiki on 1.18 or earlier, > while updating the central user management wiki to 1.19: would it be possible > to remove the dependency from the field "user_options" already in the 1.18 > code, before 1.18 is finally released? > > It would not matter if many extensions use the old option and compatibility is > impossible anyways. However, Confirm Account was the only code element that we > use that expected this field to be present, so I think it might be worth it. The problem is with the createNew() function in User. The regular "create account" interface (which admins can still usually access with ConfirmAccount and everyone can without the extension) will suffer from the same problem in this case. createNew() always tries to set user_options to "" no matter how it was called (such as by ConfirmAccount).
> The problem is with the createNew() function in User. I understand, it is core, not Confirm Account. Still: should something be done about shared user tables? Should perhaps 1.19 NOT delete the field, even if it no longer uses it?
(In reply to comment #8) > I understand, it is core, not Confirm Account. Still: should something be done > about shared user tables? Should perhaps 1.19 NOT delete the field, even if it > no longer uses it? I think Aaron's work on hetdeploy might help you with wiki-farms that use different versions of MW. But he'd have to point you to the right place. (And I could be totally off base.)
With respect to Confirm Account this bug is invalid and I close. Thanks for the support! Only the side issue remains: Aaron: if you can comment whether it would be meaningful to either suppress updating shared tables, or let the field survive a few version to support side-by-side use for a few versions. We are not aiming at a big complex, but so far side-by-side versions (we actually use it presently only for testing!) were no problem for us.
