Manual talk:Upgrading to 1.11

Please do not post support questions here.

Instead, use one of these channels:

• Project:Support desk
• the mailing list

Further options for contacting appropriate people can be found at Communication .

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;
+--------------+-----------------+------+-----+-------------------+-------+
| 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 |       |
+--------------+-----------------+------+-----+-------------------+-------+
4 rows in set (0.00 sec)

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. osteoporosis

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:

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

TJHooker 21:48, 15 September 2007 (UTC)

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 ^(index\.php.*) - [L]
RewriteRule ^(.*) /kb/index.php?title=$1 [PT,L,QSA]

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&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";
#$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

enabling exception trace shows that it failed because my old password was not "good enough" - ie same as the username or 0 characters. Changing this fixes it, but doesn't tell users trying to login why they cannot login. -- Andy Bolstridge, 2008-08-20

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

Experiences of updating 1.4.12 to 1.11.0

Got there in the end but as far as I could tell you need to run upgrade1_5.php first (release notes implied not ?) and this crashed in the script for me but had managed to create some of the new tables that update.php was expecting. Update.php also crashed with no table wiki_text but, after poring over the documentation here, I realised this is a rename (and cut down) of wiki_old and renaming that table (wiki_old to wiki_text) allowed the update.php script to run and I was there !

I probably should delete the now unused fields from wiki_text but tend to feel IIABDFI. The initial crash in upgrade1_5.php I failed to note down.

Only other point was that although I am a "reseller" of my webspace with United Hosting I discovered with the first update I did that I don't get Lock Tables permission as standard - other ISPs may also restrict this. -- Johnrcrellin 17:51, 24 November 2007 (UTC)

Unable to merge files and preserve directory structure

My hosting service does not allow me to update my mediawiki in a such a way where I replace all the core files with the new ones but keep my modifications. I have to install a fresh wiki and copy over all my personnal settings. Here is a list of the most important operations:

• Copy over the LocalSettings.php file (possibly changing the database parameter for preliminary testing)
• Copy any installed extensions.
• Copy over the images directory
• Copy any personal skins in the skin directory
• Check for any hacked scripts (like modified math.php file when installing mimetex extension)
• Change the database back after testing and run the update script !

Who was speaking of a pool side update ? XApple 10:34, 25 November 2007 (UTC)

Migration from MySQL top PostgreSQL

Are there any tools or scripts to migrate an existing wiki from mysql to postgresql database? -- 192.109.190.88 14:38, 16 January 2008 (UTC)

Open base dir restriction

When trying to run the 1.11 install I get this message:

Warning: main() [function.main]: open_basedir restriction in effect. File(/convertLinks.inc) is not within the allowed path(s): (/var/www/vhosts/gtr-tech.com/httpdocs:/tmp) in /var/www/vhosts/gtr-tech.com/httpdocs/mw/maintenance/updaters.inc on line 13

Warning: main(convertLinks.inc) [function.main]: failed to open stream: Operation not permitted in /var/www/vhosts/gtr-tech.com/httpdocs/mw/maintenance/updaters.inc on line 13

Fatal error: main() [function.require]: Failed opening required 'convertLinks.inc' (include_path='.:') in /var/www/vhosts/gtr-tech.com/httpdocs/mw/maintenance/updaters.inc on line 13

My server is running:

1. PHP: 5.0.4 (apache2handler)
2. MySQL: 4.1.20

I get the same error having tried to upgrade to 1.11.* and 1.12.*. Doing a clean install does the same thing. --Barista 21:06, 8 June 2008 (UTC)

Publishing SQL changes on file

It would be wise to publish all changes in mySQL in a file so user could update the database manually via mySQL command line.

--79.186.29.44 18:47, 9 March 2008 (UTC) (pl.wikipedia.org: Abdel)