Last modified: 2008-06-12 00:16:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14497 - CheckUser's install.php doesn't work
CheckUser's install.php doesn't work
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
PC Windows XP
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2008-06-10 16:25 UTC by Shaiaqua
Modified: 2008-06-12 00:16 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Shaiaqua 2008-06-10 16:25:52 UTC
I set up the alpha mediawiki and went to install checkuser. I ran install.php on the command-line, and it showed:
...cu_changes table added.
recentchanges is empty; nothing to add.
...cu_log added
...log file missing, skipping log import.

I then proceeded to add user rights, including checkuser, and it showed:

Database error
From Wiki
Jump to: navigation, search
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

    (SQL query hidden)

from within function "efUpdateCheckUserData". MySQL returned error "1146: Table 'wikidb.mw_cu_changes' doesn't exist (localhost)".

Effectively the table(s) were not created, and re-running the script didn't help.
Comment 1 Shaiaqua 2008-06-10 17:49:29 UTC
This happened with the current checkuser from svn and one from a month or two ago, btw.
Comment 2 Brion Vibber 2008-06-10 17:52:27 UTC
Can you check if there's a cu_changes table (without the mw_ prefix) present?

The SQL file looks like it properly lists the prefix, but if it's not taking it in that might explain the behavior.
Comment 3 Shaiaqua 2008-06-10 17:54:28 UTC
Nope, not there.
Comment 4 Shaiaqua 2008-06-11 21:59:04 UTC
In fact, there was no change to the database. It is exactly the same as before running the script. 
Comment 5 Brion Vibber 2008-06-12 00:02:59 UTC
Ok, I can reproduce this when I don't have an AdminSettings.php and my default DB user doesn't have CREATE permissions.

The sourcing of the SQL files is failing silently; the actual $db->sourceFile() call is returning an error message like this:

CREATE TABLE ...*snip*... failed with error code "CREATE command denied to user 'wikiuser'@'localhost' for table 'cu_changes' (localhost)

but it's not triggering a fatal exception, as we'd normally expect from the default config. The SQL file sourcing function is overriding the general error handling and forcing it to suppress it... which is IMHO not a good idea, as most (all?) calls to sourceFile() either are not doing *any* error checking on the result, or assume a boolean true is success without checking for string return values.

Probably would be best to remove that error override (or make it optional) and allow it to be enabled case-by-case if a caller needs it.

Shaiaqua, you can probably get it working on your system by setting up an AdminSettings.php listing your privileged MySQL account.
Comment 6 Brion Vibber 2008-06-12 00:16:56 UTC
r36211 fixes the error reporting; if you SVN up it should now show  you the database error instead of pretending it worked (la la la I CAN'T HEAR YOU :)

Note You need to log in before you can comment on or make changes to this bug.