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

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16497, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14497 - CheckUser's install.php doesn't work
CheckUser's install.php doesn't work
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CheckUser (Other open bugs)
unspecified
PC Windows XP
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  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: ---


Attachments

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.


Navigation
Links