Page MenuHomePhabricator

CheckUser's install.php doesn't work
Closed, ResolvedPublic

Description

Author: shaiaquanature

Description:
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.


Version: unspecified
Severity: major
OS: Windows XP
Platform: PC

Details

Reference
bz14497

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:13 PM
bzimport added a project: CheckUser.
bzimport set Reference to bz14497.
bzimport added a subscriber: Unknown Object (MLST).

shaiaquanature wrote:

This happened with the current checkuser from svn and one from a month or two ago, btw.

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.

shaiaquanature wrote:

Nope, not there.

shaiaquanature wrote:

In fact, there was no change to the database. It is exactly the same as before running the script.

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.

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 :)