Manual talk:Upgrading

Please do not post support questions here.

Instead,

• see Project:Support desk
• use the mailing list

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

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.

I'd be happy if someone could explain how to patch on Windows 7. Despite it being POSIX-based it does not contain the patch command or anything similar. In this case I'm running MW on Apache, but I believe the difference is the same for those silly enough to use IIS. Metalbunny (talk) 17:45, 20 September 2013 (UTC)

You can get a patch command from cygwin. -- ☠MarkAHershberger☢(talk)☣ 17:51, 20 September 2013 (UTC)

-As a novice user running a Wiki on a 1and1.com server that I am managing from a Win7 computer, I thought I would put a couple of notes on installing a patch for other novices. You will need to have the following software (or the equivalent) installed on your computer - | Filezilla (for transferring files), | 7-Zip (for opening the .gz compressed file), and | PuTTY (for logging into your server). You'll also need your 1and1 user id for the FTP and SSH log in. You can find this information in your 1and1 admin control panel.Rsoandrew (talk) 18:43, 5 April 2014 (UTC)

• Download the latest patch file. If you don't get the email updates, look in the news feed on the main MediaWiki page.
• Extract the patch to your desktop using 7-zip.
• copy the patch to your wiki's root directory (the one with LocalSettings.php)using Filezilla.
• SSH into your account using PuTTY and get into the root directory for your wiki.
• enter the following in the command line (no quotes) modifying the name of the patch file to the one you are using "patch -p1 --dry-run < mediawiki-1.22.2.patch"
• Review the output. If there are no error, run the same command omitting "--dry-run"
• Change to the maintenance sub directory and in the command line (no quotes) run "php6 update.php"
• Go to your special pages and open the version link. You should be updated. Note that if you forget to run update.php, the version page will still report that your version has been updated but things won't work right and you will get database errors. — Preceding unsigned comment added by [[User:{{{1}}}|{{{1}}}]] ([[User talk:{{{1}}}|talk]] • [[Special:Contributions/{{{1}}}|contribs]])

This recent edit is on the same problem. (The change concerning the "-i" switch obviously was wrong and has been fixed already.) --88.130.68.167 11:50, 11 August 2014 (UTC)

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)

Well, I think this would be really doable: If PHP is configured properly, it will be possible to get the new source, extract it and later run update.php. Other systems have functions to do automatic upgrades that way as well. So: Yes, having such function should be possible and for minor updates (like from 1.22.6 to 1.22.7) this really should work fine. However, once you have the seven(?) shell commands needed to do an update, you can also run them from the shell within say 30 seconds or so. However, I see that this is not the solution for the non-tech-savy user. --88.130.83.67 11:14, 29 April 2014 (UTC)

What is really needed is the wiki community coming to agreement on 5-year plans (minimum) where no changes will be made which would require overhaul of custom extensions. When it comes time to upgrade, I think of that line from Gladiator, "Unleash Hell." Pretty much every other upgrade requires hiring a programmer to go through and fix custom extensions so that they work with the upgrade. So waiting a long time before making changes that cause these issues would be widely appreciated because it causes my site to be down up to a week while the mods are made and tested.

I know there are some systems with fully automated updates already that are very user friendly. The synology servers for example (like the rackstation) have mediawiki as an "app" and it updates automatically with little to no hassle. I love those things, I have two in my house and set them up for clients all the time. So one of those systems is a great solution too, although not free.

Upgrading extensions in a git world (R1.20 and beyond)

Has anyone developed a recipe/strategy for updating their extensions on a production system? Git#Extensions seems like a starting point, but seems more geared to developers rather than site admins/end users. Special:ExtensionDistributor doesn't show 1.20.x in the release drop-down box. --Peculiar Investor (talk) 15:37, 18 December 2012 (UTC)

Well, as usual: Clone it and you have it. Then do a git pull and you do an update. --88.130.81.134 01:57, 19 January 2013 (UTC)

Cannot get command line arguments, register_argc_argv is set to false -- not a simple problem

I have a php.ini file in the same directory as the upgrade.php command that I am trying to run. It contains

register_argc_argv=true

The command I am running is:

php /home/xxxxx/public_html/mywiki/maintenance/update.php

I have removed the .htaccess file.

The permissions on the php.ini file is 644.

I have tried it with the filename php5.ini

I've tried replacing the php command to php5

What else can I do????

Thanks.

Spot for instructions needed

This needs another spot on an Azure specific page. I just moved it out of the general manual since it is too specific.

On Microsoft Azure,

Navigate an login in to:
 https://<yoursitename>.scm.azurewebsites.net/DebugConsole
In console area, goto site/wwwroot folder (via cd command) and run following command:
 php maintenance/update.php

Cheers --[[kgh]] (talk) 11:47, 22 May 2014 (UTC)

Fwd: Integrate upgrade notices in MediaWiki core interface

Tracked in Phabricator
Task T85456

Any interest in this feature? See phabricator:T85456 and if possible comment/subscribe/award token there. :) --Nemo 22:15, 29 December 2014 (UTC)

How to apply patch to mediawiki on Azure

I'm trying to patch my Mediawiki version 1.24.1 to 1.24.2. There are some clear instructions for Linux installations, but they are not valid for Azure. I'm missing the file "patch". So how do I apply the patch "mediawiki-1.24.2.patch" to the website.

Does anyone have experience or info about how to accomplish this? Thanks in advance. — Preceding unsigned comment added by Mickbravo (talk • contribs)

patch is a program that's usually available in all linux distributions. On windows you can download gnu patch from sourceforge. You need to add the executable file to the system path, or provide the full path to the patch.exe executable when running the command. --Ciencia Al Poder (talk) 13:05, 6 April 2015 (UTC)

I couldn't get it to work, so I will try to get a support case at Microsoft. Because an Azure Webapp is a shared cloud solution which will provide you with a non-administrative account. The cmd session which is available can not help me with installing patch.exe. So maybe someone another or additional suggestion. Mickbravo (talk) 12:06, 8 April 2015 (UTC)

Backup syntax

I don't see anything wrong with this syntax:

mysqldump --user=LoginName --password=MyPassword my_wiki --xml > file.xml

But I am getting a complaint, "#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'mysqldump --user=LoginName --password=MyPassword my_wiki' at line 1"

The example given was mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb --xml > file.xml

And I replaced wikidb_user with LoginName (which is the name as viewed in phpmyadmin password with the password I use to log in to the wiki, i.e. MyPassword) and wikidp with the database name as displayed by phpmyadmint as the table name wright below the information_schema table. ( also tried using the Wiki's name, but received the same failure for bad syntax.)

Any thoughts?RiverStyx23 (talk) 15:15, 11 April 2015 (UTC)

The user name and password, which you should use, are not the ones with which you log in to MediaWiki. You must use that username and password of the MySQL user. Most likely that will be the same account, which you have in the database credentials in LocalSettings.php. --88.130.67.176 15:46, 15 April 2015 (UTC)

Permissions

A line is needed in the "Unpack the new files" section specifying the permissions. CPanel doesnot allow me to upload a file without first specifying the permissions. RiverStyx23 (talk) 15:24, 11 April 2015 (UTC)

Having a look at your other question (uploading the tarball and proceeding), I would say: It does not matter. You only must be able to extract the file. To make things simple, you can even take 777 permissions; that should work in any case. After extraction you will just delete the file anyway. It is not needed anymore later. --88.130.67.176 16:02, 15 April 2015 (UTC)

To Overwrite or Not To Overwrite, That is the Question

The instructions say, "You should put the decompressed tarball in a new and empty folder on your server," but this is not consistent with the Upgrade[.txt] file, which says, "Replace the existing MediaWiki files with the new." Which is correct? How do we get the incorrect instruction corrected? RiverStyx23 (talk) 15:24, 11 April 2015 (UTC)

You might want to bring up that question in the mailing list for further discussion. If you ask me, both ways have their right to exist: For a minor update, overwriting the old files will most likely always be OK. For a major upgrade, overwriting the old files can definitely cause errors. You are right in saying that the docs should be adjusted so that they fit to each other again! --88.130.67.176 16:04, 15 April 2015 (UTC)

Where to unpack them

Assuming I'm not to overwrite, then I also assume that I can dispense with a separate backup since the current files are not being touched. My current installation is in /home/myname/public_html/w so I **think** what I'm supposed or can do is rename w to w-old then create a new directory w then put the downloaded mediawiki-1.24.2.tar.gz file in the new directory w and proceed from there. Is this correct? RiverStyx23 (talk) 15:24, 11 April 2015 (UTC)

Yes, you can use a new folder and extract the files there. You will then have to move all custom files there as described in the manual (e.g. LocalSettings.php, custom extensions, custom skins and so on). --88.130.67.176 16:00, 15 April 2015 (UTC)

Visit statistics starting from zero after upgrade

Hi. After upgrading from MW 1.21 to 1.26 on my site, accumulated visitor statistics went to zero, and now it is counting visits from there. Is it possible to somehow continue counting from the previous number of visits that I recorded, 2 million+ ? Thanks.

See Extension:HitCounters! --87.123.45.167 15:29, 7 January 2016 (UTC)

wfLoadExtension vs. "require_once"

So I've just updated from MW 1.23.7 right to 1.26.0. Everything seems to be working. But of course because I can never be too sure, I have to as this about the new method of loading extensions.

Currently, all my extensions are still using "require_once" when loaded. What I'm wondering is a) will extensions that have been adapted to work with wfLoadExtension still work properly using "require_once", and b) if I change a line to use wfLoadExtension and the extension isn't compatible, is there a way I can immediately know, or would I have to wait for something to break miserably? Schiffy (talk) 00:46, 18 December 2015 (UTC)

While the require_once() way of loading extensions should still be working, it is recommended to migrate to the new wfLoadExtension() approach. This will work for all extensions, which come with an extension.json file. --87.123.45.167 15:30, 7 January 2016 (UTC)

Password not correct after upgrade with wgSharedTables set (Wikifamily)

Hi,

how is it possible that after maintenance/update.php from MW 1.20.7 to 1.27wmf7 my login password on non-upgraded Wikis of the wiki farm is not accepted any more? On the upgraded Wiki I can login with the password but not on non-upgraded Wikis. I thought the option --doshared which is not active by default prevents any changes on shared tables. So I assume the shared tables are not touched at all during upgrade but somehow they are. (1) Is this expected or a BUG? (2) Is there an official procedure to prevent that? --Andreas P. 10:55, 18 December 2015 (UTC)

May this have to do with session handling and cookies? --Andreas P. 13:37, 18 December 2015 (UTC)

For what I've seen in the code, every update on a field or a table checks if the table is a shared one. For this, it checks that $wgSharedDB is not null and that the table is not in $wgSharedTables.

The problem seems to be the change in password hashing, as you can read in RELEASE NOTES of 1.24:

* The default password type for MediaWiki has been changed from MD5 to PBKDF2.
  Password hashes will automatically be updated as users log in. If necessary, the
  old MD5 hashing can be restored by changing $wgPasswordDefault to 'B'. In addition,
  there is a maintenance script wrapOldPassword.php that can wrap all passwords in
  PBKDF2 (or the hashing algorithm of your choice) if you don't want to wait for your
  users to log in.

So whenever a user logs in on the upgraded wiki, it won't be able to login on the non-upgraded one. You should change $wgPasswordDefault on all wikis until you upgrade all of them, --Ciencia Al Poder (talk) 16:58, 18 December 2015 (UTC)

Puh! Yes it woks to have
$wgPasswordDefault ='B'; /* old MD5 hashing on shared Wikifamily with pre MW1.24 and post MW 1.24+ Wikis */
… to log in old and new Wikis. Thank you! --Andreas P. 17:19, 18 December 2015 (UTC)

Problem with the special pages after upgrading to MW 1.26 from 1.22

Hi, After I upgrade to MW 1.26 or MW 1.25, from MW 1.22 I get a "Fatal exception of type MWException" error each time I visit any Special Pages. Including recent changes I have been googling and trying different solutions posted but none of them worked.

Does anybody have an idea of what could be happening?

this is the link of my website in case someone need more details

http://respaldo.wikiexplora.com/index.php/Especial:P%C3%A1ginasEspeciales

Thanks a lot in advance

Juan Pablo Ortega. 19:32, 19 December 2015 (UTC)

Hola Juan Pablo. Tendrías que activar Manual:$wgShowExceptionDetailsManual:$wgShowExceptionDetails para poder ver detalles del error. Idealmente tendrías que preguntar estas cosas en Project:Support desk --Ciencia Al Poder (talk) 13:34, 20 December 2015 (UTC)

También deberías revisar en LocalSettings.php que no hayan espacios en blanco al inicio del archivo antes de "<?php", y que al final del archivo NO haya una etiqueta de cierre "?>". Viendo el código HTML generado por el wiki observo hasta 7 líneas en blanco al inicio que pueden causar problemas, --Ciencia Al Poder (talk) 13:39, 20 December 2015 (UTC)

Muchas gracias Ciencia al Poder, activar el $wgShowExceptionDetails me fue de gran ayuda para identificar el problema, googleando llegué a que se debía a una extensión discontinuada de Google Maps

comenté el código y wa la!! funcionó nuevamente. El código era require_once( "$IP/extensions/GoogleMaps/GoogleMaps.php" ); --Juan Pablo Ortega. 12:21 am, 21 December 2015 (UTC)

Updating php

I am not an expert and have had difficulties in updating the MediaWiki on my Synology NAS from MW 1.23 to 1.26. When trying to approve revisions using extension:Approved Revs, I would get an error such as:

A database query error has occurred. This may indicate a bug in the software.

Query: INSERT IGNORE INTO `pagelinks` (pl_from,pl_from_namespace,pl_namespace,pl_title) VALUES ('568','0','10','AnemometerCalibrationQualitySystem'),('568','0','0','Anemometer_Calibration_Quality_System') Function: LinksUpdate::incrTableUpdate Error: 1054 Unknown column 'pl_from_namespace' in 'field list' (localhost)

Apparently I hadn't updated the database correctly. Rather than $ php update.php

I hade to run: $ php56 update.php

I hope others can benefit from this. Sohansenit (talk) 10:57, 30 June 2016 (UTC)

No Patch for 1.27.0?

Under https://releases.wikimedia.org/mediawiki/1.27/ the only patch listed is mediawiki-1.27.0-rc.1.patch.gz The -rc in the filename seems to indicate this was a release candidate. Is there a patch for the actual 1.27 release, or will one be made available? Tcrimsonk (talk) 21:38, 5 July 2016 (UTC)

Patches aren't provided for upgrading from one major version to another. Only for point releases. That's probably because it's difficult to tell from which version you're upgrading... Maybe you were still using 1.26 until 1.27.2 appears... Whenever a new minor release comes up, the .0 patch would become obsolete. --Ciencia Al Poder (talk) 00:41, 6 July 2016 (UTC)

Shared server + multiple Mediawiki installations

If you are running on a shared server and have multiple Mediawiki installations, then you might be seeing a MWException Error. This happens because the default setting for $wgTmpDirectory is at the root of the server (/temp folder) and so multiple Mediawiki installations are now sharing the same temp folder. Obviously this will cause problems since temp content of one wiki will overwrite the content of another. Here is the official bug report.

Luckily there is an easy fix to address this. Just add a custom temp directory to LocalSettings.php. Example code: $wgTmpDirectory = "$IP/images/temp";

Yet it turns out that the code above makes the temp files publicly viewable. I'm not sure if that matters but it's better to be safe. Here is an optimal solution which keeps the temp files hidden: $wgTmpDirectory = "{$wgUploadDirectory}/tmp/uniquename"; — Preceding unsigned comment added by Nuclearsugar (talk • contribs)

I don't see where it's suggested to point $wgTmpDirectory to $IP/images/temp. The correct approach would be to point to /tmp/wiki/$wgDBname or similar. --Ciencia Al Poder (talk) 02:11, 19 July 2016 (UTC)

Indeed, there is no documentation of what to do in this situation and I was just trying to share my findings with others for posterity. I apologize for my amateur perspective, I'm not a developer. — Preceding unsigned comment added by Nuclearsugar (talk • contribs)

Web updater is not enough to maintain a MediaWiki installation

Although the web updater is suggested as a tool to substitute running update.php from shell, it seems to have problems with e.g. creating the appropriate database tables for an installed extension. A good example is at Topic:T4myd7tg3qgfcvnx. This means that these functionalities are not usable with ftp-hosted wikis (a substantial share in the world of MediaWiki).

Is web updater really lagging behind update.php? How can this be solved? Bozonbozon (talk) 09:54, 30 November 2016 (UTC)

Need to customize $wgTempDirectory on shared hosting

I recently upgraded from 1.25.2 to 1.28.0. Followed the steps here but was getting errors about not being able to access a file in /tmp/. It took me a while to track it down, but sounds like 1.27 introduced a file with a specific name in the temp directory, which is incompatible with shared hosting unless everyone uses a unique temp directory. I didn’t need that before I upgraded, so $wgTempDirectory wasn’t set and it was using the default /tmp/, just like everyone else. Everything was fine once I added $wgTempDirectory = '/tmp/mydomain'; to LocalSettings.php. It would have been nice if that was easier to find, or if it had been mentioned on the upgrading page, so I’m adding it to the discussion page.

Misterhaan (talk) 16:16, 3 February 2017 (UTC)

Setting $wgReadOnly causes error when running update.php

If one follows the suggestion in "Can my wiki stay online while it is upgrading?" to set $wgReadOnly, there is a sub-script started by update.php that balks and reports that the database is read-only. My workaround was to remove $wgReadOnly from my LocalSettings.php before running update.php, but this prevents making the wiki read-only during the update. A catch-22. If we are suggesting setting $wgReadOnly, we need to warn readers to remove it before running update.php.