Manual talk:Upgrading to 1.6

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 .

Images Not Displaying

I just upgraded from 1.4.6 to 1.6.3, and everything works fine - except for one thing. I moved all my images over to the new install, but now none of my images are found by the wiki. It puts a placeholder link to the image, and when you click on it, it takes you to the image, and the image is there, but for some reason none of the pages have any of their images displaying. Has anyone else experienced this issue? My logo is missing also, and it says "Set $wgLogo to the URL path to your own logo image" - but as near as I can tell, the path is correct. I am using my old LocalSettings.php file, and per the release notes, $wgDisableUploads has been replaced with $wgEnableUploads.12.106.111.10 23:21, 24 April 2006 (UTC)

I have exactly the same problem (except the logo), I upgraded from 1.4.5 to 1.6.8. Any suggestions? --192.102.158.90 13:36, 2 October 2006 (UTC)

I think, I found the solution myself. Running the maintenance script rebuildImages.php has fixed the images except 2 of them, that were linked lowercase instead of leading uppercase letter. --192.102.158.90 14:59, 2 October 2006 (UTC)

Orphaned?

Hi, Really useful page - more info than in the mediawiki tarball - but it is a page with nothing linking to it! Nor does it belong to a category. 1.6 is a big thing! This page should be linked to from the Mainpage and other installation related pages. Sorry I don't have time to sort it myself just now. I don't even have an account yet. Cheers, David --84.92.127.242 18:04, 5 April 2006 (UTC)

Hi David. I'm attempting to update as much of the documentation as possible, fitting it around a lot of other things. I cobbled this together less than 48 hours before we were due to release 1.6.0 and didn't link to it much until afterwards. It's now linked to from the UPGRADE file in the distribution files, and I expect it'll be linked to quite a bit from other places.

Once we get the documentation on this site organised, I suspect things will fall into place better. For now, I'm considering adding a link on the sidebar. Rob Church 03:57, 10 April 2006 (UTC)

Skin problem

Anyone else getting "fatal error: call to undef" instead of a menu bar after upgrading? --Cuthbert 00:35, 6 April 2006 (UTC)

1. Can you confirm you updated all the files?
2. Can you confirm that $wgSkinDirectory is correct in LocalSettings? (should be 'skins' not 'stylesheets')
3. Can you provide the exact error message? The URL to a page showing the problem is good too.

--Brion VIBBER 05:29, 6 April 2006 (UTC)

I received a similar error after following the upgrade procedure. On checking the page source, I got the exact message:

<b>Fatal error</b>: Call to undefined function: wfnomsg() in <b>/tch/trap/public_html/wiki/skins/MonoBook.php</b> on line <b>129</b><br />

I had only changed files in the 'common' folder in /skins, so I replaced the rest of the folders and files with the ones included in the 1.6 package (though I imagine just replacing /monobook would suffice) - problem solved, and all is good and working. --Lokiz0r 02:25, 13 April 2006 (UTC)

You can fix this error by changing the function wfNoMsg to wfEmptyMsg in your skin. Cheers--Biyer 19:04, 2 May 2007 (UTC)

Error upgrading database

During updating from 1.5.8 to 1.6.1 (using method of deleteng LocalSetings.php file) I got following message:

PHP 5.0.4 installed
PHP server API is apache2handler; ok, using pretty URLs (index.php/Page_Title)
Have XML / Latin1-UTF-8 conversion support.
PHP is configured with no memory_limit.
Have zlib support; enabling output compression.
Neither Turck MMCache nor eAccelerator are installed, can't use object caching functions
GNU diff3 not found.
Found GD graphics library built-in, image thumbnailing will be enabled if you enable uploads.
Installation directory: C:\dev\www\enviwiki
Script URI path: /enviwiki
Environment checked. You can install MediaWiki.
Warning: $wgSecretKey key is insecure, generated with mt_rand(). Consider changing it manually.
Generating configuration file...
Database type: mysql
Attempting to connect to database server as root...success.
Connected to 4.1.18-nt; enabling MySQL 4.1/5.0 charset mode
Database enviwiki exists
There are already MediaWiki tables in this database. Checking if updates are needed...
DB user account ok
...hitcounter table already exists.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...logging table already exists.
...validate table already exists.
...user_newtalk table already exists.
...transcache table already exists.
...trackbacks table already exists.
...externallinks table already exists.

Creating job table...Query "CREATE TABLE `job` (

 job_id int(9) unsigned NOT NULL auto_increment,
 job_cmd varchar(255) NOT NULL default '',
 job_namespace int NOT NULL,
 job_title varchar(255) binary NOT NULL,
 job_params blob NOT NULL default '',
 PRIMARY KEY job_id (job_id),
 KEY (job_cmd, job_namespace, job_title)
 ) ENGINE=InnoDB
 " failed with error code "Specified key was too long; max key length is 1024 bytes (localhost)".

Can somebody help me? -- Jiri

This is a known problem occurring in some configurations, reported at bugzilla:4445. See comment #5 there for a possible workaround (although the consequences haven't been tested). Rob Church 04:11, 10 April 2006 (UTC)

Upload all files

The article for this page actually says this:

Replace all the existing files from MediaWiki 1.5 with the new ones from 1.6, preserving the directory structure.

It doesn't really mean to just replace only the current files with new versions of them, does it? I guess that it means to upload all of the new files in 1.6 to the same location as 1.5 is stored, so that newer versions of some files will overwrite previous versions, and some new files will be written also. Is this correct? I am a little, in fact a lot, scared about doing this, so I want to be sure. - JohnE

You're correct; replace the lot and add new. Also, don't be scared; make backups to cover your ass and everything will be fine. :) Rob Church 03:57, 10 April 2006 (UTC)

--- I got the following error after installation:

A database error has occurred
Query: SELECT   user_name,user_password,user_newpassword,user_email,user_email_authenticated,user_real_name,user_options,user_touched,user_token,user_registration    FROM `wiki_user` WHERE user_id = '2' LIMIT 1
Function: User::loadFromDatabase
Error: 1054 Unknown column 'user_registration' in 'field list' (localhost)

Backtrace:

   * GlobalFunctions.php line 602 calls wfbacktrace()
   * Database.php line 473 calls wfdebugdiebacktrace()
   * Database.php line 419 calls databasemysql::reportqueryerror()
   * Database.php line 806 calls databasemysql::query()
   * Database.php line 825 calls databasemysql::select()
   * User.php line 720 calls databasemysql::selectrow()
   * User.php line 667 calls user::loadfromdatabase()
   * Setup.php line 229 calls user::loadfromsession()
   * index.php line 80 calls require_once()

Any help on understanding what to do now would be appreciated, a lto. - JohnE

You didn't run the updater. --Brion VIBBER 06:39, 11 April 2006 (UTC)

Sorry, I don't understand. What updater? I used the web method to re-run the installer as stated in the article. Do I have to do something else also? Sorry for not understanding this. - JohnE

Now, I see that I didn't have an AdminSettings.php file in the wiki directory as required, but only a AdminSettings.sample file. It is unclear whether I need to have this using the web installer method. Anyway, I have now made a copy of the .sample file to .php and updated the DBadmin settings in it. It also asks for a true/false for $wgEnableProfileInfo. Where can I find out if I need this or not, please? - JohnE

Now that I have run the install of new 1.6.2 SW without the AdminSettings.php being in place, what do I need to do to recover from this? Can I just save the AdminSettings.php in the wiki root and re-run the installer? Actually I just tried this and it didn't work. I presume that I need to delete the 1.6.2 SW and upload the old 1.5 Wiki files from my backup. And then go back to the MySQL backup from that time, check that that works again, and then start the reinstall of 1.6.2 again. Is this right? - JohnE

As far as I can tell, your schema is still in the old 1.5 format, so set up an AdminSettings.php file and select one of the methods referred to at Manual:Upgrading_to_1.6#Run_the_update_script. Rob Church (talk) 11:00, 19 May 2006 (UTC)

Very bad for me

My eld version is 1.5.6, and I select use "Experimental MySQL 4.1/5.0 UTF-8" (Database charset). My PHP is 5.1.2 (cli) and is Ver 14.12 Distrib 5.0.18, for pc-linux-gnu (i686) using readline 5.0 (Apache 2 is 2.0.55).

After I upgrade to 1.6.1, and then I can not add Chinese article (title is Chinese). If I edit Chinese article (title is Chinese), I get like this:

数据库错误
数据库指令语法错误。这可能是由于非法搜索指令所引起的(见 $5), 也可能是由于软件自身的错误所引起。最后一次数据库指令是：
   (SQL query hidden)
来自于函数 "Title::getLinksTo"。 MySQL返回错误 "1267: Illegal mix of collations (latin1_bin,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' (localhost)"。

And I can not do upgrade of maintenance/refreshLinks.php. I get similar error.

I how to do now? My old wiki have many Chinese article (title is Chinese). Now I have no idea to back 1.5.6 (I forgot backup mysql use mysqldump). Can I back to eld use mysql log system?

Help me. Thanks. --Opentiss 03:10, 10 April 2006 (UTC)

What was the method used to perform the upgrade? Rob Church 04:11, 10 April 2006 (UTC)

• I use web to upgrade. And I did not set binlog, I forgot the suggestion of upgrade: I did not use mysqldump backup the database. And now I can not go to back. Can you help me? Or give me some suggestion? :(

--Opentiss 06:12, 10 April 2006 (UTC)

• And I from 1.5.6 to 1.6.1 is same test on SuSE 9.1( select "Experimental MySQL 4.1/5.0 UTF-8" of "Database charset" ).

--Opentiss 06:19, 10 April 2006 (UTC)

• Error message is here(command line: php refreshLinks.php):

Refreshing link table.
Starting from page_id 1 of 1723.
A database error has occurred
Query: SELECT page_namespace,page_title,page_id  FROM `page`,`templatelinks`  WHERE (tl_from=page_id) AND tl_namespace = '0' AND tl_title = '首页' 
Function: Title::getLinksTo
Error: 1267 Illegal mix of collations (latin1_bin,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '=' (localhost)

Backtrace:
GlobalFunctions.php line 602 calls wfBacktrace()
Database.php line 482 calls wfDebugDieBacktrace()
Database.php line 419 calls Database::reportQueryError()
Database.php line 815 calls Database::query()
Title.php line 1557 calls Database::select()
Title.php line 1581 calls Title::getLinksTo()
LinksUpdate.php line 102 calls Title::getTemplateLinksTo()
LinksUpdate.php line 68 calls LinksUpdate::doIncrementalUpdate()
refreshLinks.inc line 93 calls LinksUpdate::doUpdate()
refreshLinks.inc line 64 calls fixLinksFromArticle()
refreshLinks.php line 22 calls refreshLinks()

<!-- Served by wiki in 0.76 secs. -->

--Opentiss 06:28, 10 April 2006 (UTC)

I find something, 1.5.6 (in my mysql database, mysqldump sql):

DROP TABLE IF EXISTS `templatelinks`;
CREATE TABLE `templatelinks` (
 `tl_from` int(8) unsigned NOT NULL default '0',
 `tl_namespace` int(11) NOT NULL default '0',
 `tl_title` varchar(255) character set latin1 collate latin1_bin NOT NULL default '',
 UNIQUE KEY `tl_from` (`tl_from`,`tl_namespace`,`tl_title`),
 KEY `tl_namespace` (`tl_namespace`,`tl_title`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

1.6.2 (in my temp test wiki mysql database, mysqldump sql):

DROP TABLE IF EXISTS `templatelinks`;
CREATE TABLE `templatelinks` (
 `tl_from` int(8) unsigned NOT NULL default '0',
 `tl_namespace` int(11) NOT NULL default '0',
 `tl_title` varchar(255) character set utf8 collate utf8_bin NOT NULL default '',
 UNIQUE KEY `tl_from` (`tl_from`,`tl_namespace`,`tl_title`),
 KEY `tl_namespace` (`tl_namespace`,`tl_title`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

I think this is main problem. And I find the templatelinks is empty, so I do like this(in my mysql database of from 1.5.6 to 1.6.1):

DROP TABLE IF EXISTS `templatelinks`;
CREATE TABLE `templatelinks` (
 `tl_from` int(8) unsigned NOT NULL default '0',
 `tl_namespace` int(11) NOT NULL default '0',
 `tl_title` varchar(255) character set utf8 collate utf8_bin NOT NULL default '',
 UNIQUE KEY `tl_from` (`tl_from`,`tl_namespace`,`tl_title`),
 KEY `tl_namespace` (`tl_namespace`,`tl_title`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

And the result is ok. Very great. And maybe this is a bug from 1.5.6 to 1.6.*. Do you think so? And I find the table externallinks,job,transcache is same problem. --Opentiss 09:04, 10 April 2006 (UTC)

Upgrading from 1.4.x

What should users of the 1.4 branch do? Upgrade to 1.5, then 1.6? Or try to go straight to 1.6? —Mjb 05:37, 11 April 2006 (UTC)

Up to you; both should work. Be sure to make backups. Also, I'd read around for all the 1.4.x → 1.5 documentation; there's a bigger jump, and quite a few things can get cocked up, e.g. charsets, images, etc. Rob Church (talk) 00:54, 12 April 2006 (UTC)

Yeah, my attempt to upgrade 1.4.5→1.5.4 in January resulted in massive breakage, mainly due to a table that it was trying to access that didn't exist in 1.4.x. I managed to fix it by downgrading to 1.4.14. I'm afraid to try again. I looked around and couldn't find any upgrading info though. That's why I'm asking here. Any pointers appreciated. Thanks—Mjb 04:47, 15 April 2006 (UTC)

after upgrading some images arn't shown

I have a similar problem. At first, image upload didn't work on my webspace provider (ouvaton) whereas mediawiki 1.4 is fine.

I got this message:

Fatal error: mime_magic could not be initialized, magic file is not available in /data/www/e/x/ample.ouvaton.org/html/wiki/includes/MimeMagic.php on line 504

I found on some forums that adding this piece of code in the LocalSettings.php

$wgMimeDetectorCommand = "file -bi";

Allowed me to upload, but then got this following alert:

Warning: shell_exec(): Cannot execute using backquotes in Safe Mode in /data/www/e/x/ample.ouvaton.org/html/wiki/includes/MimeMagic.php on line 470

And image resizing (for thumbnails) is not working and give me the following alert:

Warning: shell_exec(): Cannot execute using backquotes in Safe Mode in /data/www/e/x/ample.ouvaton.org/html/wiki/includes/GlobalFunctions.php on line 1615

Although this is not essential, any help would be usefull. Many thanks in advance ! Lilious 13:59, 16 May 2006 (UTC)

How to Lock Database before taking a backup

Can anyone point me to how to lock the database before taking a backup so that there are no problems doing this, and restoring from it later. - JohnE

FLUSH TABLES WITH READ LOCK

If you use MySQL for your database (you haven't said), then you can use mysqldump and it will handle the necessary details for you. Example:

# cd /backup/yoursite
# mysqldump -p -A > yoursite.`date +%Y-%m-%d`.sql

I backup my MediaWiki database file that way. Caveat: I am a novice. My notes on how I backup MediaWiki are here: http://wikigogy.org/User:Roger/Bu --Rogerhc 04:00, 22 June 2006 (UTC)

Error (missing table) when upgrading from 1.4

Hello,

I tried to upgrade my http://sapwiki.iwoars.net to 1.6.5, everything works, except the content of the articles. :-((

First I got the error:

   (SQL query hidden)

aus der Funktion "Revision::loadText". MySQL meldete den Fehler "1146: Table 'wikidb.sapwikitext' doesn't exist (localhost)".

That was true, there was no table sapwikitext in the database. I created it by hand according to tables.sql form the maintainence directory. So the error message dissapeared but still no text in the articles. On database level I can see the texts in the table cur. Everything els seems to work. Special pages, versions, but no text.

Any hints?

MatthiasKabel 20:27, 19 May 2006 (UTC)

The upgrade didn't work if the text table wasn't created and populated. Restore to a consistent, backed-up version, if possible, then repeat the upgrade procedure again. robchurch | talk 07:06, 1 November 2006 (UTC)

Upgrading from 1.6.5 -> 1.6.6

Alright, first off, sorry if this has been anwsered, or explained somewhere. I tried searching, but, I couldn't seem to find anything. Also, sorry if this is a stupid question. (Which I'm fairly sure it is.)

Anyway, here is my question, I don't need to go through all of these steps if I'm already on 1.6, do I? If not, am I also not needing to upgrade my database? If so, would just replacing the old files with the new ones suffice? Thanks, and again, sorry if it's stupid, and or obvious.

/edit Also, sorry if this is in the wrong spot. -71.127.94.94

My experience is that the upgrade from 1.6.5 to 1.6.6 was clean. I simply copied the new files into the appropriate place in my htdocs and everything worked.

Yeah, thanks for the response. I also got a response here, which echoed your response. Did it, and it seemed to work great. -71.127.94.94

Is it the same for 1.6.9 -> 1.6.10 ? --68.90.189.99 03:26, 21 March 2007 (UTC)

Error upgrading 1.5.0 to 1.6.6

While upgrading using the command line
php updage.php

I got this message

... > more lines precede
Setting page_random to a random value on rows where it equals 0...changed 0 rows
Initialising "MediaWiki" namespace...
A database error has occurred
Query: INSERT  INTO `text` (old_id,old_text,old_flags) VALUES (NULL,'[[$1]] moved to [[$2]]','utf-8')
Function: Revision::insertOn
Error: 1048 Column 'old_id' cannot be null (localhost)

Backtrace:
GlobalFunctions.php line 602 calls wfbacktrace()
... < more lines follow

Just for kicks, I modified the db to allow nulls in old_id. Then I got a similar error on the revision table for rev_id. But, that is the primary key so, I couldn't set it to allow nulls. Then I tried upgrading using the browser and got the same error. I am wondering what I should try next? Fredrc 00:36, 30 May 2006 UTC

I figured out a fix for my problem, I had to alter my tables adding "AUTO INCREMENT" to the id columns that were affected. I was also moving my db from one server to another which forced me to downgrade mysql from 4.1 to 4.0. I am not sure at this point if I had removed the auto increment in the process, or if the 4.0 db just needed that in addition to being a primary key. Anyways I am up and running now. Fredrc 3:15pm, 4 June 2006 PDT

Indeed, I experienced exactly the same problem when migrating an experimental mw db (mysql server v.5.x) to a production site (running a mysql v.4.x)... I used the export and import process from phpmyadmin interfaces, but forgot to check the "dump auto-increment data" option... I compared the exported and imported databases and found out that there are several columns involved: primaries from _ipblocks, _page, _recentchanges, _revision, _text, _trackbacks and _user. Just modify these columns (set the "extra" field to "auto-increment") or redo your export and import process not forgetting to check the auto-increment option... Have fun! -- Philippe Marty from Grid'5000 project 20:00, 05 July 2006 CET

I also had this problem, I was trying to move my wiki from a server with mysql 5.x to 4.0. First I exported with phpmyadmin with the compatibility set to 4.0, and even though I added the auto_increment option, it didn't work till I added the auto_increment myself (manually) to the dump sql file (as an extra field). Only then it worked. Hopes that helps. -- 20060-08-14

I experienced this when upgrading a MediaWiki 1.5 to 1.6. If you have a server where only the mysql console is running, the following will add auto_increment (to table "text" on column "old_id"):

ALTER TABLE text MODIFY old_id INT UNSIGNED NOT NULL AUTO_INCREMENT;

In a similar fashion, I also updated revision/rev_id, page/page_id, ipblocks/ipb_id, recentchanges/rc_id, trackbacks/tb_id, user/user_id. Note that not all of those are natively "INT UNSIGNED" but it usually should not hurt to use this. To do this manually with any version of MediaWiki, have a look at meta:Help:Database layout --Markus Krötzsch 12:52, 15 August 2006 (UTC)

I also had this problem when moving my wiki between a new machine (and OS). The fix above corrected it perfectly.

had the same problem, please note you have to alter the logging table ALTER TABLE `logging` CHANGE `log_id` `log_id` INT( 10 ) UNSIGNED NULL AUTO_INCREMENT

How do I overwrite the existing installation?

Sorry for this one, but I cannot figure out how to easily overwrite the existing installation with the new tarball. The tarball has mediawiki-1.x.x in the base path, so tar xvzf extracts to a parallel directory, not over the top of my existing directory. I can rename my existing installation to this first, but there must be a cleaner way.

You could use a symlink that you can delete and point to the new package.

man tar, perhaps? :) robchurch | talk 07:05, 1 November 2006 (UTC)

error after upgrading 1.5.x to 1.6.0 : call-time pass-by-reference

The update seems to be clean but when i surf on the main page of my wiki, i get :

Warning: Call-time pass-by-reference has been deprecated - argument passed by value; If you would like to pass it by reference, modify the declaration of array_unshift(). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. However, future versions may not support this any longer. in includes/Parser.php on line 2617

I set to true in ini file but it does not change anything (I used ini_set to set the allow_call_time_pass_reference to "true"). Someone has an idea ? Thanks

Edit : Well in a hurry I just put double slashes (//) at the beginning of line # 2617 in Parser.php and it has solved my problem. The line contains : //array_unshift( $funcArgs, &$this, substr( $part1, $colonPos + 1 ) );

So i'll write this nevertheless for those who have the same problem. And it was from an upgrade of 1.5.4 to 1.6.0

Don't comment out the line - instead, remove the & - i.e. use $this instead of &$this. On a side note... why do you upgrade to 1.6.0? 1.6.8 would be a better choice, i guess. -- 84.185.230.76 23:12, 15 August 2006 (UTC)

Upgrading from 1.5.3 on Windows to 1.6.8

I've got a WikiMedia installation of v1.5.3 on a Windows hosted server and it's working great, but I want to upgrade it to take advantage of new features, security updates, etc. Since I only have PHP 4.4.4, I can't go up to v1.7 yet, so I'm trying to do 1.6.8. How do I do this upgrade? I do not have access to the physical server and I cannot run command-line instructions such as php update.php. Is there a specific set of upgrade instructions for this scenario? Thanks!

AdminSettings.php

I attempted to link "Adminsettings.php" in the "Run Updater" section, but it appears that I am not allowed to make edits to that page. For those of you interesting in learning more about Adminsettings.php, see m:AdminSettings.php.