Manual talk:Upgrading to 1.11

Alternative 1: phpShell
This is only working when you have php.exe in a path. If you don't have that you have to use a command-line like: $ "c:/phpdirectory/php.exe" "c:/wikidirectory/maintenance/update.php"

If you are using windows you can start cmd.exe and put above line without the $ and it works as well. Londenp 15:18, 14 September 2007 (UTC)

Problem with change to categorylinks index
I am using PHP5 and MYSQL5. Got error: Checking if categorylinks index cl_sortkey includes field cl_from... ...index cl_sortkey on table categorylinks has no field cl_from; adding Query "ALTER TABLE `wm_categorylinks` DROP INDEX cl_sortkey, ADD INDEX cl_sortkey(cl_to, cl_sortkey, cl_from) " failed with error code "Specified key was too long; max key length is 1000 bytes

(hostname here)

This was similar to a problem I had with the wm_job(?) table on first installation, which I think related to an assumption that databases used latin1 characters rather than utf8 (which use 3 bytes per character instead of one). So I made the following change to /maintenance/archives/patch-categorylinksindex.sql -- JW adding (160) to fix problem ALTER TABLE /*$wgDBprefix*/categorylinks DROP INDEX cl_sortkey, ADD INDEX cl_sortkey(cl_to(160), cl_sortkey, cl_from);

By the way the table, before the change above looked like this: mysql> show columns from wm_categorylinks; +--+-+--+-+---+---+ +--+-+--+-+---+---+ +--+-+--+-+---+---+ 4 rows in set (0.00 sec)
 * Field       | Type            | Null | Key | Default           | Extra |
 * cl_from     | int(8) unsigned | NO   | MUL | 0                 |       |
 * cl_to       | varchar(255)    | NO   | MUL |                   |       |
 * cl_sortkey  | varchar(86)     | NO   |     |                   |       |
 * cl_timestamp | timestamp      | NO   |     | CURRENT_TIMESTAMP |       |

This worked but I would appreciate a comment on whether the reduced key size will create problems for the future. Thanks. Jonathan3 00:51, 15 September 2007 (UTC)


 * I am having the same problem but the (160) trick isn't working, and I know we're running utf-8. php5 and mysql5. Any ideas? ThePoet444 11:04, 25 September 2007 (UTC)
 * Nevermind I just switched the table to latin-1 and it worked fine. ThePoet444 11:42, 25 September 2007 (UTC)

Hook wfCallLoadMessages failed to return a value
upgrading from 1.9, mysgl5.0, PHP5.1.x

Installation went throug, I also edited in the wiki. Added a simple line in in MessagesEn.php, reverted this.

When logging out the following error occured:

Internal error

Detected bug in an extension! Hook wfCallLoadMessages failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

TJHooker 21:48, 15 September 2007 (UTC)
 * 1) 0 /home/tango.info/vhost_wiki/w/mul/includes/MessageCache.php(683): wfRunHooks('LoadAllMessages')
 * 2) 1 /home/tango.info/vhost_wiki/w/mul/includes/User.php(2531): MessageCache->loadAllMessages
 * 3) 2 /home/tango.info/vhost_wiki/w/mul/includes/Title.php(1189): User::getGroupName('user')
 * 4) 3 /home/tango.info/vhost_wiki/w/mul/includes/Title.php(1024): Title->getUserPermissionsErrorsInternal('edit', Object(User), false)
 * 5) 4 /home/tango.info/vhost_wiki/w/mul/includes/Title.php(996): Title->userCan('edit', false)
 * 6) 5 /home/tango.info/vhost_wiki/w/mul/includes/ParserCache.php(33): Title->quickUserCan('edit')
 * 7) 6 /home/tango.info/vhost_wiki/w/mul/includes/ParserCache.php(46): ParserCache->getKey(Object(Article), Object(User))
 * 8) 7 /home/tango.info/vhost_wiki/w/mul/includes/Article.php(687): ParserCache->getETag(Object(Article), Object(User))
 * 9) 8 /home/tango.info/vhost_wiki/w/mul/includes/Wiki.php(383): Article->view
 * 10) 9 /home/tango.info/vhost_wiki/w/mul/includes/Wiki.php(48): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
 * 11) 10 /home/tango.info/vhost_wiki/w/mul/index.php(89): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
 * 12) 11 {main}

Endless Redirect Loop
Upgrade from 1.10 to 1.11 went through smoothly (incl. php update.php), but broke the installation.

Any access to the wiki results in an endless redirection for .../Mainpage ! Note: The wiki is running behind a reverse proxy, thus $wgServer and $wgScriptPath are set to non-local hostname and script path (which works perfect with 1.10).

Japanese Full Text Search in Postgres
If you want to handle japanese text in the tsearch2, you require Postgres 8.2.x(patch for version 8.2.1). --Courant 11:13, 22 September 2007 (UTC)


 * PostgreSQL: Documentation: Manuals: PostgreSQL 8.2: Release 8.2.2(/contrib/tsearch2 localization improvements (Tatsuo, Teodor))
 * PostgreSQL information page(Mr Tatsuo's home page 2007/01/15)

Performance Problems after upgrading from 1.9.3 [Solved]
I experienced severe performance problems (20s delay before a wiki page was delivered) when I upgraded from version 1.9.3. By comparing my custom LocalSettings.php with one from a new and fresh 1.11.0 install, I found out that inserting the line $wgDBTableOptions  = "TYPE=InnoDB"; in my LocalSettings.php solved it. --195.226.123.200 14:40, 25 September 2007 (UTC)

Rewrite failure
For an install in http://example.com/kb/ I have the following in LocalSettings.php:

$wgScriptPath      = "/kb"; $wgArticlePath = "/kb/$1";

And the below in .htaccess:

RewriteEngine On RewriteBase /kb RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*) /kb/index.php?title=$1 [PT,L,QSA]
 * 1) RewriteRule ^(index\.php.*) - [L]

This worked great in MediaWiki 1.10; however, after the upgrade, this breaks things by causing any edit to edit a page called "/index.php" (i.e. index.php?title=/index.php&amp;action=edit). I can't solve this one on my own for some reason; so now I'm asking what's wrong here. Short URL path guides don't help either...

The temporary work-around involves commenting out $wgArticlePath to make pages go to normal paths.

$wgScriptPath      = "/kb";
 * 1) $wgArticlePath = "/kb/$1";