Manual talk:Upgrading

This has just been changed back into a redirect with the reason "less work, more up-to-date", however I think this page had a useful purpose, which is more than a simple 'upgrading to the latest version' page can offer.

Is there any objection to re-instating the page as it was?

--HappyDog 13:28, 4 June 2007 (UTC)

I would prefer to see the below content integrated into the main Manual:Upgrading page. I tend to agree that multiple pages with overlapping content or goals should be merged and formatted in a more reader-friendly way perhaps if the content is just overwhelming as is.

Just my two cents.  :) --Varnent 23:51, 17 December 2011 (UTC)

Error

Setup.php must be included

When i try to run: $ php update.php --aconf ../AdminSettings.php

I got the following error: Error, Setup.php must be included from the file scope, after DefaultSettings.php.

What do I do? --Bluesoju 16:51, 29 June 2009 (UTC)

Can't create table

" failed with error code "Can't create table './wahes_db/querycache_info.frm' (errno: 121) (localhost)" What to do 216.135.135.218

Call to a member function addMessage() on a non-object in

In this release $wgMessageCache is completely removed (see Manual:$wgMessageCache). Extension using this feature doesn't work anymore. Is there any scripts to upgrade extension written using $wgMessageCache?

Any answer to this?

I encountered this with Open Web Analytics. I just commented out the lines. I had to manually add its one message, but that was no big deal. Dcoetzee (talk) 02:35, 10 April 2012 (UTC)

No SSH shell available

I can't access to a command line, or an SSH shell or similar and so I can't run $ php update.php --aconf ../AdminSettings.php

so, how can I update the database?

--anonymous 13:51, 20 June 2009 (CET)

Language Error

My English Sites has Hebrew and Arabic Languages throughout. When I upgraded to 1.15.1 the languages came out looking like this Εκκλησια הגרים הגרים התושבים התושבים הגרים עבד ×§× ××™ صابئة صابئين مسلم WikiNoah Admin

continue getting error

Hi

whenever I try the update, i get the follwing error message: MediaWiki 1.15.1 Updater

A connection to the database could not be established. Check the values of $wgDBadminuser and $wgDBadminpassword.

I am quite sure the values are correct. I am using Produkt Version MediaWiki 1.15.1 PHP 5.2.9 (apache2handler) MySQL 5.1.35 with MacOS X

can anybody help?

Regards MOh

Hi M0h,

I've solved it, by setting $wgDBserver to "127.0.0.1"; in LocalSettings.php Regards exe

MySQL 5.4

By the way, just for reference, MySQL 5.4beta3 x64 Windows Binary seams to be working fine, see here if youd like to see an example.

This script must be run from the command line

cant run the upgrade script from firefox

INDEX command denied to user

i am trying to upgrade a number of wikis [1.11.0 and 1.11.2] to 1.15.1. on virtually all the upgrades i am getting an error:

MySQL returned error "1142: INDEX command denied to user '$WIKIadm'@'localhost' for table 'pagelinks' (localhost)"

the problem being that on each of them, when i go into mysql and issue a show grants, all of those users have INDEX:

mysql> show grants for '$WIKIadm'@'localhost';
+---------------------------------------------------------------------------------------------------------------+
| Grants for $WIKIadm@localhost                                                                                 |
+---------------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO '$WIKIadm'@'localhost' IDENTIFIED BY PASSWORD '$PASSWORD'                               |
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, LOCK TABLES ON `$WIKI`.* TO '$WIKIadm'@'localhost'       |
+---------------------------------------------------------------------------------------------------------------+
2 rows in set (0.01 sec)

so what gives?

You need to set grant for index(It is not in the list, use all when setting, if this is confusing set it $wgDBadminuser='root' and use root user.

---

212.251.167.205 20:48, 13 October 2010 (UTC)

Where do you come from?

I realy miss the clear description whether or not you may upgrade from earlier versions of MW than the predecessor of the announced version. To give an example: I was asked by a customer: Can I upgrade from version 1.9 directly to the newest MW version? and being not well educated in MW my self, I had no proper reaction to make.

Are there restrictions? What restrictions may exist when you have a lot of Extensions installed? OK I accept that you have to find out for each extentention whether or not it supports the version to be installed. But nevertheless a warining for that should be in place here.

Again, may experience on this subject is too low to make changes myslef so please make soma improvements on this subject in the page if you can. JanEnEm 06:46, 25 April 2010 (UTC)

Great! Tim Starling did me (and others I hope) the favor introducing a FAQ section that amongst others answers the subject I raised here. Thanks Tim! JanEnEm 18:34, 5 May 2010 (UTC)

Applying a patch

The demarcation between MW specific and OS/other issues is not always obvious. Applying a patch is one of them.

I spent the best part of a day hunting for information about how to apply a MW patch to no avail. Since it is central to the quick application of MW security fixes I think it would be useful to have at least a 'patch file application basics' somewhere on the MW site. Anyway here's what I eventually came up with - posted here in hopes it may help somebody:

Applying a MW patch file requires the Unix 'Patch' utility to be available (or equivalents on other OS's). Detailed usage/syntax instructions are here but the following worked for me on Centos 5.4:

1. Extract the tar.gz to the wiki root directory.
2. Execute the command "patch -i PATCHFILENAME -p 1

The '-p 1' parameter strips the first part of the pathname from each of the files to be patched. This is necessary because the MW patch files specify each file to be patched from the domain root using the full release specification name as the first directory down from the domain root.

Once you've got it, the whole process takes just a few minutes. Having gone through about 10 installs/upgrades since starting with MW about 9 months ago, I'm fairly proficient at it. However, for bona-fide patches - especially important security ones - the patch process is well worth becoming proficient with.

Upgrading from 1.17alpha to a newer version of 1.17alpha

Are there any difficulties that will occur when upgrading from 1.17alpha to a newer version of 1.17alpha? I have a wiki that I want to keep always on the cutting edge (or close to it) of MediaWiki core development, but I guess this will require frequent upgrades and running of update.php. Would any problems arise in doing that? Tisane 02:59, 26 May 2010 (UTC)

I don't think so. I always do the same on my wiki --Diego Grez ^{return fire} 03:00, 26 May 2010 (UTC)

Upgrading DB

If I install new version of MW (1.15=> 1.16), will a DB update automatically???

-- 18 June 2010

No. You have to run Update.php. 109.229.103.223 14:09, 14 September 2010 (UTC)

Method not implemented error

I've hit an intermittent problem that I cannot track down. It goes like this:

Occasionally when editing an existing, or authoring a new article I get the following error when either previewing or saving changes:

Method not implemented. Post to /w/index.php not supported

I use pretty urls which may or may not be relevant. The problem has only appeared since upgrading from 1.16beta3 to 1.16.0. (Although it is just possible that an upgrade to both php and mysql a few days earlier is implicated). I also thought I'd got the trigger when I found that an article exhibiting this problem contained an unclosed 'blockquote' tag and closing it got rid of the error on that article; but it has since happened several times since with no such obvious trigger present.

I have run setup.php with no problems and the site seems to operate as before in all respects save for this glitch. Any suggestions/observations welcome --Sabretache 07:31, 13 August 2010 (UTC)

Turns out this is an Apache Mod_Security issue. Haven't figured out how to implement the precise exception yet but I'm getting there. Anyone with advice to offer welcome. --Sabretache 15:49, 13 August 2010 (UTC)

--User teamspeak Info 18:21, 11 November 2010 (UTC)

I have the same error. It seems be problem with Apache Mod Security on this page i found how to disable mod_security using .htaccess file (for now i wainting when my host provider give me a best solutions) Any info about disable mod_security only for index.php and only when special group sending POST or GET request is wellcome. Info also here

Upgrade - How?

Dear MediaWiki readers.

I'm using MediaWiki on a free webhosting service, and decides to upgrade from 1.15.0 to 1.16.0, but runs into some troubles. According to the manual, I shall locate the update script, and open it. Yeah okay, I find a update.php inside Maintenance, but I can't open it because a damn htaccess file. Well, okay, when that failed, I just for fun checked the directory config but nothing useful there.

I have to disappoint You: I do not have server access, nor SSH access, I only have FTP and HTTP access to my website, so how the h. can I upgrade, without losing all my data?

- Mikkel Trebbien, Denmark.

Manual:Upgrading#Alternative_2:_Re-run_the_installer. Max Semenik 19:34, 14 August 2010 (UTC)

Done - Installing extensions again. Obviously the only way to do so, but thanks. - Mikkel Trebbien, Denmark.

MW 1.16 Upgrade From 1.15

MediaWiki 1.15.1 PHP 5.3.2-1ubuntu4.2 (apache2handler) MySQL 5.1.41-3ubuntu12.6

This was the original and after installing and following all directions it still remains such in the Special : Version page.

My files show the folder as MW 1.16 /var/lib/mediawiki/mediawiki-1.16.0

I ran the updater and the relevant message was: PHP Deprecated: Comments starting with '#' are deprecated in /etc/php5/cli/conf.d/mcrypt.ini on line 1 in Unknown on line 0 MediaWiki 1.15.1 Updater

Going to run database updates for wikidb

Then it ran the updates successfully and that's that.

I am on localhost and run the wiki as a personal thing.

Any help appreciated!

1091 mysql error

I get this error when upgrading to 1.16. Any help?

Adding ls_field_val key to table log_search... Ha ocurrido un error de sintaxis en una consulta a la base de datos. La última consulta a la base de datos que se intentó fue: "ALTER TABLE `log_search`

DROP PRIMARY KEY,
ADD UNIQUE INDEX ls_field_val (ls_field,ls_value,ls_log_id)

" desde la función "DatabaseBase::sourceStream". Base de datos retornó error "1091: Can't DROP 'PRIMARY'; check that column/key exists (localhost)". --217.216.40.30 21:55, 8 October 2010 (UTC)

I got past this error by giving the table a primary key, which the alter table command in the update scripts can then remove:

mysql> alter table log_search add primary key (ls_field);

But my upgrade seems to have failed anyway, so maybe not so helpful :p --170.146.225.4 21:18, 7 February 2012 (UTC)

Update multiple wiki instances

Hello, I ran the update from 1.15.1 to 1.16.2. I did run the update.php, however, it doesn't seem to update all my db. It updates wikidb but not all my prefixes. I have about 6 instances of wiki running, all separated with different prefixes in the same db. How can I update all my instances? Please let me know. Thanks!

Alternatives a mission impossible?

If an user have only HTML and FTP access, and "If I install new version of MW (1.15=> 1.16), will a DB update automatically??? No. You have to run Update.php" it's an mission impossible to udate a wiki? --Lastwebpage 17:41, 2 April 2011 (UTC)

Mediawiki v1.17 error install, point to this page

PostgreSQL MediaWiki 1.17.0 installation.

A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: Manual:Upgrading#Run the update script

Query: SELECT lc_value FROM l10n_cache WHERE lc_lang = 'pt-br' AND lc_key = 'deps' LIMIT 1 
Function: LCStore_DB::get
Error: 1 ERROR: relation "l10n_cache" does not exist

Table l10n_cache exist, but "is mediawiki.l10n_cache", then is a PHP bug for not null schemas.

See includes/LocalisationCache.php

...relation "msg_resource" does not exist

 See includes/MessageBlobStore.php

All need SCHEMA reference for postgreSQL.

Hi. I faced similar problem. It seems related to the fact that upgrading from 1.15 to 1.17 some tables are not created by the update process (despite the fact that mysql user has the right permission). The tables not created are l10n_cache, search_log, user_properties, msg_resource, msg_resource_links (I don't known if there are more, but after creating those and related index the wiki started). A complete table definition is reported in maintenance/table.sql. Hope this help --GB 15:31, 31 July 2011 (UTC)

undefined function mysql_error()

I have a problem with upgrading my local wiki from v 1.15.1 to the newest one. I've been following the instructions and while trying to run update.php all I got was only this:

MediaWiki 1.17.0 Updater

PHP Fatal error:  Call to undefined function mysql_error() in XXXXXXX\wiki\i
ncludes\db\DatabaseMysql.php on line 234

Unfortunately I'm stuck at this point. How can I solve it? Please help me.

PS: Part of path is removed due to privacy. 178.183.191.232 22:30, 8 July 2011 (UTC)

EDIT Fixed the problem myself. I had to change extension of old LocalSettings.php file, then recreate new one using setup creator and after typing login and password to my own little database I could upgrade.

Pain in the... (you can finish this sentence) :/

178.183.191.232 22:51, 8 July 2011 (UTC)

upgrading from 1.15. to 1.17 stall

I'm trying to upgrade a 1.15 existing mediawiki installation to 1.17. The process stall at

Populating log_search table, printing progress markers. For large databases, you may want to hit Ctrl-C and do this manually with maintenance/populateLogSearch.php.

and no progress. I cannot open a php console to run install.php by command line. Just poor old http... Any hints? --GB 13:46, 31 July 2011 (UTC)

Well, made some investigation and it seems that some (new?) tables are not created, including log_search. I created by hand with phpMyAdmin following table.sql schema and mw started. I'have still problems with my custom skin based on monobook but probably this is not db problem related. I'll check all the table in table.sql against my present db schema. --GB 15:15, 31 July 2011 (UTC)

It should be safe to run the installation script multiple times until it finishes. —Emufarmers^(T|C) 06:47, 6 August 2011 (UTC)

Upgrading MW. Run update.php - "Cannot redeclare wfgetdb()"

Hi,

I've backed up my database, unpacked the tarball into the wiki's current directory. I ran the update.php script from the maintenance directory. And my shell gave me an error (domain name edited out):

Cannot redeclare wfgetdb() (pre in *path*/includes/DatabaseFunctions.php:50) in /home/*domain*/pubcludes/GlobalFunctions.php on line 3196

70.71.150.1 01:31, 6 August 2011 (UTC)

DatabaseFunctions.php was removed in r63241, but it would be left over if you unpacked the new files over the old ones. I'm not sure how it's getting included, though. —Emufarmers^(T|C) 06:44, 6 August 2011 (UTC)

Problems with upgrading from 1.16.5 to 1.17.0

1. GNU diff3 is not found, even though these are specified in LocalSettings.php:

# Path to the GNU diff3 utility. Used for conflict resolution.

$wgDiff3 = "/usr/bin/diff3";

$wgDiff = "/usr/bin/diff";

2. Upgrade script says Success when it finishes updating the database. However, I noticed errors that one of the tables was nonexistent. These tables cause errors unless you manually add them to your database. You can install a new database (blank) and export them and then import them into your existing database, or you can manually add these table to your database. I hope I don't have problems because I'm using MyISAM with my other database tables and these are set to InnoDB (and they have multiple keys, so I think it's required to use InnoDB):

• Iwlinks_table -- says it's 1.17.0 (this caused the error upon submitting edited text)
• Manual:Module_deps_table -- says it's only the Trunk version
• Manual:Msg_resource_table -- says it's only the Trunk version
• Manual:Msg_resource_links_table -- says it's only the Trunk version

Hi, we're aware of this problem, see here. Would be great if you added yourself to CC list on that to be able to provide feedback, because we still can't reproduce it. Max Semenik 01:41, 22 August 2011 (UTC)

Fatal Error when upgrading from 1.16.0 to 1.17.0

I recieve this error when the web updater is trying to update my database:

Fatal Error: Class 'FakeMaintenance' not found in XXXXX/wiki/includes/installer/DatabaseUpdater.php on line 66

How do I fix this? --98.232.245.206 23:13, 27 August 2011 (UTC)

Try replacing includes/AutoLoader.php with this. Next time, please ask on Support desk. Max Semenik 06:06, 28 August 2011 (UTC)

PostgreSQL schema update errors (1.15 -> 1.17)

Problem

I tried to upgrade my MediaWiki from version 1.15 to 1.17 using the commandline method by running update.php in the /maintenance directory. Although the first few schema updates went ok (all sequence rename operations), the log_log_id_seq to loggin_log_id_seq and pr_id_val to page_restrictions_pr_id_seq rename operations failed because in a previous operation they had been created. Apparently, Postgres behaves different from MySQL in this regard failing whith a serious enough error to halt the update script.

Temporary fix

Fixed this by manually duplicating both sequences with their new names, starting at wherever the 'old' sequence was at (peeked at the create script that pgAdmin III showed me), and updated the id columns of the logging and page_restrictions tables to point respectively to the newly created sequences in each default function (showing nextval('...'::regclass)). After that I commented both the # new sequences lines:

//array( 'addSequence', 'logging_log_id_seq'          ),
//array( 'addSequence', 'page_restrictions_pr_id_seq' ),

as well as the two corresponding # renamed sequences lines:

//array( 'renameSequence', 'log_log_id_seq',      'logging_log_id_seq'          ),
//array( 'renameSequence', 'pr_id_val',           'page_restrictions_pr_id_seq' ),

in /includes/installer/PostgresInstaller.php. Found this after backtracing the error message and the objects involved from update.php to /Maintenance.php looking for getCoreUpdateList in relation to Postgres.

Alternative temporary fix

If update script hasn't been executed yet, simply remove or comment out lines 25 and 26 from includes/installer/PostgresUpdater.php

//array( 'addSequence', 'logging_log_id_seq'          ),
//array( 'addSequence', 'page_restrictions_pr_id_seq' ),

If the update script has already been executed, restore your backup or do what is suggested above (untested).

If the update script has already been executed, just delete those new sequence: DROP SEQUENCE logging_log_id_seq; DROP SEQUENCE page_restrictions_pr_id_seq; and try this alternative temporary fix again. 109.60.112.140 07:47, 9 January 2012 (UTC)

Suggestion

Working with Postgres (as I have experienced with lots of extensions as well) differs more than most programmers expect. It might be worth the effort to abstract these differences through a more generic database layer for the whole MediaWiki framework. But that, of course, should be discussed elsewhere on the fora or this site :-)

--3BDesign 16:28, 10 October 2011 (UTC)

---

Fatal error ParserCache.php after upgrade from 1.16 to .17

I have upgraded MW from 1.16 into 1.17 and after I have got such a message on mainpage:

Fatal error: Call to undefined method User::optionsHash() in /includes/parser/ParserCache.php on line 186

When I acces directly to the pages it works fine but on the main page i can find this message. What is wrong ? Arek (212.14.11.13 13:31, 20 October 2011 (UTC))

Skin Error upgrading from 1.16.5 to 1.18.1 (tooltipAndAccesskey)

I received the following error:

Original exception: exception 'MWException' with message 'Call to undefined method SkinCustomName::tooltipAndAccesskey' in \includes\Skin.php:1567

It appears "tooltipAndAccesskey" no longer exists as a method of the Skin class. Does anyone know how to update the custom skin so it still works?

soultion

Replace it with tooltipAndAccesskeyAttribs

Frank

Delete config and mw-config for security???

Shouldn't the two directories and files inside be deleted after the upgrade procedure?

Additionally, after running the web-based installer, after the database upgrade, the page goes to an error page. This would confuse the users. If the user navigates back to the upgrade file, then he is told that the upgrade succeeded. Why can't the updater redirect to the success page automatically??? MKRD info 16:40, 24 November 2011 (UTC)

In MW 1.18 the folder "config" is no longer needed and also does nolonger come with the source code. If you use MW 1.18 and have this folder, you can safely remove it. Removing "mw-config" would add an extra layer of security. However, I think it should also be save to leave this folder as is: It is protected by some special key, which you must enter, when you want to use the installer. To be able to use it, you must edit LocalSettings.php and add this key there. If an attacker has reached the stage, where he can modify the files in your webspace (to add this key), you have lost anyway, so you can then also leave this folder in place. But if you remove "mw-config", you will have the drawback that you will not be able to go through the web installer again (whyever you might want to). --88.130.80.237 12:27, 26 March 2012 (UTC)

Test

I recently moved my wiki from my Windows machine to an Ubuntu (linux) virtual machine. I imported the database tables and the files, ran the upgrade process (via the web) which seems to work fine, but now my wiki is in a sort of "read only" mode: I can view pages, but anything that requires a submission to the server (User log in, Create New User, Edit page), fails and returns you to the original page without any explanation.

The page here says to "Test the Update", but not what to do if that test fails. Any suggestions?? --Mr Minchin 19:37, 27 November 2011 (UTC)

Hmm, would be interesting to know where exactly things do not work for you: E.g. when you open the edit view, or when you actually try to save a page? I would expect that in this case you should get some errors in the PHP error log or maybe in the MySQL error log. --88.130.80.237 12:22, 26 March 2012 (UTC)

"Cannot redeclare wfprofilein()"

If you're upgrading to MediaWiki 1.18 and getting the error

"Cannot redeclare wfprofilein()"

then remove

require_once( dirname(__FILE__).'/includes/ProfilerStub.php' );

from StartProfiler in your root directory.

php update.php returns nothing and system not upgraded.

I tried to follow all the upgrade instructions but when I got to the run php update.php from the command-line, it returns very quickly with no feedback whatsoever. And it obviously did nothing to make the upgrade work because every page I try from the new wiki is completely blank.

Explaination: This was due to errors loading some of php files in the added extensions.

Problems upgrading from old version

I've upgraded before without problems, but this time I realized one of my sites had not been upgraded since version 1.11, and was long overdue. I uploaded the new files and ran the upgrade routine, but like one of the comments above noted, the new tables were not created. So I've been manually creating and modifying them, and finally got the wiki to run. Unfortunately, there is still at least one error I can't seem to figure out how to get rid of. I am getting the following error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "IndexPager::reallyDoQuery (LogPager)". Database returned error "1176: Key 'log_user_type_time' doesn't exist in table 'logging' (xxxxx.xxxxx.net)".

I ran rebuildall.php with the hope that it would create whatever was missing (an index?). I don't see any field called log_user_type_time in the table 'logging', so I assume this is a missing index. I can't find any documentation about log_user_type_time. Can anyone point me in the right direction? Thanks.

Also, since I don't seem to be alone in having the problem that tables are not being updated after upgrading (never had this problem with previous upgrades) I'm wondering if this is a bug. -- Sam 10:43, 18 January 2012 (UTC)

You may have added some or even all columns to your database, but the key log_user_type_time is still missing. Running update.php won't fix this, as it only checks for the column "log_user_text" and if that one is there, the patch, which should among other things add this key, is not applied. You can execute

ALTER TABLE logging DROP COLUMN log_user_text;

Then rerun update.php which should now pick that full patch. --88.130.80.237 12:19, 26 March 2012 (UTC)

Newbie Upgrade Help

I am very sorry but i am pretty new with the mediawiki system and i really dont know how to upgrade from 1.18.0. i dont understand the instruction and hope somebody could explain it more easy for me.

We can surely help you, but you first need to tell us, what exactly you did not understand. We won't repeat you everything, which already is on the Upgrading page. And I guess when you take some time and go through it step by step, you will notice that it's not that hard. ;-) --88.130.80.237 12:14, 26 March 2012 (UTC)

wfrunhooks error when upgrading from 1.15 to 1.18

Fatal error: Cannot redeclare wfrunhooks() (previously declared in /home/stgeorge/public_html/sgs/wiki/includes/GlobalFunctions.php:3630) in /home/stgeorge/public_html/sgs/wiki/includes/Hooks.php on line 146

I get the above error message when running the upgrade script. I am currently on 1.15.4 and trying to upgrade in one hit to 1.18.1 using the web updater method. I copy the files to the site then enter the path .../mw-config/index.php and that's when I get the above error message.

Paul

Any plans to automate Upgrading Mediawiki?

There are lots of people I bet that use mediawiki that are not tech savvy enough to perform an upgrade. Are there any plans to automate this process in the future? Would be nice.

Seconded! In particular, my shared host has Git access, but only for developer accounts--they don't have it a'la carte, and have told me they don't want to add that feature or a subscription-like feature that would give me the Git access to make updating at least a BIT easier. I think MediaWiki should take a page from Wordpress and find Admin Panel on the Web ways to allow for automatic checking of new versions of MediaWiki and installed, active extensions. --Azurite (talk) 21:07, 14 May 2012 (UTC)

That would be difficult without running a bot-like script, because PHP does not work well for things like that. Besides, that would be a big overhead for large wikis that may have more than one server.--Jasper Deng (talk) 21:58, 14 May 2012 (UTC)

update.php

Could someone please explain how to run the update.php file using ssh. I am on a local MAMP server and I have been looking around for two hours online for a simple explanation as to how to navigate and run commands using terminal. "CD" doesn't seem to work. Someone should make a wiki with that info. Thank you! 24.130.249.87 21:51, 26 February 2012 (UTC)

What exactly happens, if you try using cd? We won't be able to fix a "does not seem to work".

Use

cd wiki/maintenance

or cd ../path/to/the/foldername-with-my-wiki-in-it/maintenance or something like that to bring you to the maintenance folder. Then run

php update.php

This is the way to go. If it's a local machine where you have direct access to the files (e.g. using a file commander or so) you could also navigate to the maintenance folder there and run the file update.php by double clicking on it (make sure it is associated to the PHP executable and Apache and MySQL are running). --88.130.80.237 12:11, 26 March 2012 (UTC)

Special:SpecialPages

After upgrading from 1.10.1. to 1.18.1 most of the wiki looks fine, but Special:SpecialPages does not show up. The special pages themselves are accessible.

• MediaWiki 1.18.1
• PHP 5.2.14 (apache2handler)
• MySQL 5.0.26

Any piece of advice is welcome. --ThT (talk) 10:57, 2 March 2012 (UTC)

Updating all extensions did the trick. --ThT (talk) 09:01, 5 March 2012 (UTC)

1.18.2 Notice

I upgrade 1.18.1 -> 1.18.2 and i get

Notice: A non well formed numeric value encountered in /path/to/mediawiki/includes/CryptRand.php on line 379
Notice: A non well formed numeric value encountered in /path/to/mediawiki/includes/CryptRand.php on line 380

Is normal? Mkepler (talk) 17:29, 23 March 2012 (UTC)

I also get it.

I have also the same problem on http://www.enviwiki.cz but on the other hand I have not this problem on another wiki http://vcsewiki.czp.cuni.cz - both are running on the same linux server. --Jirka Dl (talk) 10:32, 26 March 2012 (UTC)

I got it, too. It messes up my pages. It seems like some string operations with random numbers:

               // Once the buffer has been filled up with enough random data to fulfill
               // the request shift off enough data to handle the request and leave the
               // unused portion left inside the buffer for the next request for random data
               $generated = substr( $buffer, 0, $bytes );
               $buffer = substr( $buffer, $bytes );

11:28, 26 March 2012 (UTC)

Please create an issue in the issue tracker so that a developer can take care and fix that. --88.130.80.237 12:05, 26 March 2012 (UTC)

resolved this with thanks to tom melly.

edit CryptRand.php and replace line 285:
$bytes .= $iv;
with:
$buffer .= $iv;

Fatal error upgrading from 1.17.0 to 1.18.2: Call to a member function getDbType() on a non-object in maintenance/doMaintenance.php on line 91

When trying to update from 1.17.0 to the latest (1.18.2 at the moment of writing this), I encountered this message:

Fatal error: Call to a member function getDbType() on a non-object in maintenance/doMaintenance.php on line 91

The update script has garbled DB and I had to restore both files from 1.17.0 and DB to have the site back.

Does anyone know how to handle this strange behaviour? There are no modified files in my Mediawiki installation. Does it mean I can't upgrade without completely re-installing the site ab initio?

Boyandin (talk)

You should extract the 1.18.2 source code into a new folder. Then move your LocalSettings.php and the folders images/, extensions/ and skins/ there as well and try from there. MW 1.18 has problems, if there are left overs from an older version. (But I think the Upgrading page says that as well.) --88.130.80.237 12:04, 26 March 2012 (UTC)

Manual Upgrade using CPanel

I went through the process of upgrading from mediawiki 1.15 to 1.18.3 using cpanel only, without shell access and without wget. I had a few problems but nothing major. I documented the experience here at [1] just in case anyone else out there has to use the same process and gets the same errors.

Corkipedia

Which files to copy from the old installation?

Got interesting question from IRC - if unpacking a new MW version to a new directory (recommended), which files from the old setup should be copied? (only "images")? My general advice would be to verify all paths in LocalSettings.php, but probably some nice answer should be given here.  « Saper // talk »  20:15, 4 May 2012 (UTC)

MediaWiki 1.19.0 update.php stalls at "have page_len field in page table"

Hi, I tried several times to run the MediaWiki 1.19.0 Updater, but it always stalls at "have page_len field in page table". I'm waiting for about half an hour again right now. The database is about 200 MB big. I can't find any problems in my error_log. When I upgraded from MediaWiki 1.18.0 to 1.18.2 everything went pretty fast, so can it really take that long this time? Here is the output of my shell:

# php update.php
MediaWiki 1.19.0 Updater

Going to run database updates for <database_name>
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick) ... 0
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...already have interwiki table
...indexes seem up to 20031107 standards.
...hitcounter table already exists.
...have rc_type field in recentchanges table.
...have user_real_name field in user table.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...have pagelinks; skipping old links table updates
...il_from OK
...have rc_ip field in recentchanges table.
...index PRIMARY already set on image table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...logging table already exists.
...have user_token field in user table.
...have wl_notificationtimestamp field in watchlist table.
...watchlist talk page rows already present.
...user table does not contain user_emailauthenticationtimestamp field.
...page table already exists.
...have log_params field in logging table.
...logging table has correct log_title encoding.
...have ar_rev_id field in archive table.
...have page_len field in page table.

Any ideas are more than appreciated! Thanks + cheers, --Till Kraemer (talk) 20:44, 8 May 2012 (UTC)

I rebooted the server, restored the database (to 1.18.2), rebooted the server again and ran update.php again. This time everything worked perfectly. Weird... Cheers, --Till Kraemer (talk) 00:32, 9 May 2012 (UTC)

P.S.: This time I also deactivated all extensions in the LocalSettings.php before running update.php. I reactivated them after the update was done. --Till Kraemer (talk) 07:03, 9 May 2012 (UTC)

Thanks for sharing your experiences with upgrading to MW 1.19. It is probably best to post your question at the Support Desk, which usually generates more input (not a lot but some) than this page. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 10:09, 10 May 2012 (UTC)

Big databases on a shared host

I just noticed that this sentence has been added a while ago: "Do not use the web version if your database is already big." It begs two questions. First, what counts as big? Can anyone give approximate figures? 2000 MB? 8000 MB? And second, what to do if you're on a shared host and your database has grown whatever is considered big. Cavila ^{MW 1.17, MySQL 5.5.16, Php 5.3.8} 10:15, 10 May 2012 (UTC)