lensowiki:Installation caveats

Upon installing the Mediawiki software, I ran into a few problems. Here, I document fully functional workarounds and solutions to the problems I encountered.

MySQL table field lengths

New installations

The current MediaWiki install, 1.11.0, will run into two problems upon trying to initialize all the initial MySQL tables if those tables are encoded in UTF8. The reason this happens is that KEY fields are limited to 1000 bytes, and each character takes up 3 bytes in UTF. When the key fields contain a combination of columns whose combined number of bytes exceeds 1000, the installation will bail.

The obvious solution to this is to encode your tables in a different encoding. But what if you want to still use UTF8? There is a solution.

As of 1.11.0, there are two tables affected by this problem: categorylinks and jobs (The key is 2 * (255 255 8) = 1032). Both of these changes need to be made in /maintenance/tables.sql before running the initial configuration.

In categorylinks, you need to change the following line:

 KEY cl_sortkey(cl_to,cl_sortkey,cl_from),

to

 KEY cl_sortkey(cl_to(160),cl_sortkey,cl_from),

To find the line, open the file in your favorite text editor, and search for /cat. Scroll down until you see the original line as shown above.

In jobs, you need to change

 KEY (job_cmd, job_namespace, job_title)

to

 KEY (job_cmd(166), job_namespace, job_title(166))

To find the line, search for /jobs. Scroll down until you see the original line as shown above.

This guarantees that they keys are short enough so that the install won't bail.

Upgrades

Upgrades are plagued by the same problem and require a similar workaround. However, the files to patch are /maintenance/archives/patch-categorylinksindex.sql and /maintenance/archives/patch-job.sql, respectively. You might also need to change KEY cl_sortkey(cl_to,cl_sortkey) to KEY cl_sortkey(cl_to(253),cl_sortkey) in /maintenance/archives/patch-categorylinks.sql.

References

These bugs are actually filed on the MediaWiki bugzilla. See

• http://bugzilla.wikimedia.org/show_bug.cgi?id=4445
• http://bugzilla.wikimedia.org/show_bug.cgi?id=1322

Interwiki links

The initial interwiki table does not include the shorthand keys w, m, and mw; you have to add them manually. However, even after you add them, you have to create at least one new interwiki link for the MediaWiki software to "re-read" the interwiki prefix table and actually make the links functional. You only need to do this once as an administrator, and the newly-created link can then be immediately deleted.

References

• http://meta.wikimedia.org/wiki/Help:Guide_for_system_administrators_for_setting_up_interwiki_linking#Admin_tips

Short article URLs

When $wgArticlePath = "$wgScriptPath/$1" and Apache rewrite rules look something like the following:

Options FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?title=$1 [L,QSA]

any URLs containing index.php as part of a fully-qualified URL (such as http://wiki.lensovet.byethost12.com/index.php?title=lensowiki:Installation_caveats&action=edit) will be parsed incorrectly by the MediaWiki software. A patch provided by Zach Dennison works perfectly to remedy this situation. In essence, add the following lines at line 121 in includes/WebRequest.php:

/**
* If $raw starts with the script path, followed by the script,
* then we need to remove it so that things like stylesheets
* load properly when using rewrite rules.
*/
global $wgScriptPath, $wgScriptExtension;
$scriptLen = strlen( "$wgScriptPath/index$wgScriptExtension" );
if( substr( $path, 0, $scriptLen ) == "$wgScriptPath/index$wgScriptExtension" ) {
  $path = substr( $path, $scriptLen );
}

(these should go between $base = str_replace( '$1', '', $base ); and $baseLen = strlen( $base );).

References

• http://bugzilla.wikimedia.org/show_bug.cgi?id=11428

Updating MySQL on Mac OS X

I just went through a prolonged ordeal to upgrade MySQL from 5.1.30 to 5.1.47, so I'm going to write down some steps so that I don't hit so many dead-ends in the future.

The installer does not detect the presence of an older installation, and as a result, leaves the old data directory untouched. In retrospect, you could probably just move it and all would be well. Alternatively, you can recreate your databases as well. Here's what I did.

1. First, to run the mysql_upgrade script, enable the root user in Directory Utility (which is now in CoreServices, or accessible from the Account prefs prefpane).
2. su -
3. su _mysql -c "/usr/local/mysql/mysql_upgrade"
4. logout
5. Restart MySQL

Now, secure the root/guest accounts, create the wiki user and the wiki db and grant privileges. Go into LocalSettings.php and change the connection settings so that it doesn't try to connect to the DB until you are done with the rest. Then

1. sudo mkdir /usr/local/mysql/etc
2. sudo mkdir /usr/local/mysql/etc
3. su -
4. su -m _mysql -c "touch /usr/local/mysql/etc/my.cnf" (you can safely ignore the getcwd error)
5. logout
6. Turn off root user
7. Add this to the my.cnf file:

[mysqld]
max_allowed_packet=10737418

1. Restart MySQL again
2. Fire up SequelPro and import the SQL dump made earlier. Errors related to disallowed DROP operations are fine.

CS projects
Production software	FMenu — WebGrabber
Class projects	CS 61b
Misc	MediaWiki Installation caveats – Sony Clie on Mac OS X – Black screensaver