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)


 * I had to add (160) on to both cl_to and cl_sortkey to get it to work for me. -- Malvineous 01:51, 6 October 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
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)


 * I have to correct myself: The "solution" was obviously not inserting $wgDBTableOptions but setting $wgReadOnly to "false", see Bug #11533. --195.226.123.200 14:18, 2 October 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";
 * This may be related to this title extraction bug which is posted on bugzilla --Zven 03:17, 1 October 2007 (UTC)

All pages show "There is currently no text in this page, you can search for this page title in other pages or edit this page."
I just upgraded to 1.11 and now all pages show a "There is currently no text in this page, you can search for this page title in other pages or edit this page." error.

If I visit Special:Allpages, I do see the complete list of pages though.

I'm clueless currently on how to fix this problem.

Cannot login after upgrade
I just upgraded my Mediawiki installation from 1.10 to 1.11 and now i cannot login anymore, having a look at the `user` table shows me user_password is filled and user_newpassword is empty, is this the source of the problem? --Sebastian Mendel, 2007-10-09


 * using maintenance/changePassword.php did not solve the problem --Sebastian Mendel, 2007-10-09

Please add a "Known Problems" type section
I've just spent far too much time tracking down what appears to be a known bug. I finally found it by reading the "Rewrite failure" discussion section above. Please place it prominently on this Upgrade instructions page -- it will save someone a lot of time wondering why their aliases for pretty URLs suddenly broke. --Brainsik 05:05, 12 October 2007 (UTC)

After upgrade 1.10 => 1.11: Image-upload doesnt work
Theres a problem with the directory-design in the upload directory   /images, if Safe_Mode = on. Before upgrade there was only the directory /image, /archive and /thumb. Now $wgSaveDeletedFiles is disabled and cannot be use anymore. Mediwiki would like to generate a deeper filestructure e.g. /image/thumb/handzettel/handzettel.jpg. I know, that "$wgHashedUploadDirectory" exists, and its set to false. Now heres the problem: The webserver couldn't write in the /imgage directory, because of the wwwrun-problem. Pictures can not be upload. The Problem is unsolved. By the way: Is there a workaround? -- Markus, Mainz, 10:30, 21. Okt. 2007