Manual talk:Upgrading/Archive 2

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.

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

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 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, 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 06:44, 6 August 2011 (UTC)

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</tt> lines: //array( 'addSequence', 'logging_log_id_seq'         ), //array( 'addSequence', 'page_restrictions_pr_id_seq' ),

as well as the two corresponding # renamed sequences</tt> 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</tt>. Found this after backtracing the error message and the objects involved from update.php to /Maintenance.php looking for getCoreUpdateList</tt> 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 //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)

I use PostgreSQL, but except for the schema this could apply for other databases, as well. Debian 7 (Wheezy) upgrade had this, too (Debian mediawiki 1:1.19.5-1 ). Remove "mediawiki." if you use the public schema or use MySQL. "wikiuser" is my db user name

From /var/log/postgresql/postgresql-9.1-main.log:

From /etc/mediawiki/LocalSettings.php: hbswn (talk) 21:04, 22 May 2013 (UTC)

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 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)

Multi-version upgrade is a single step
Manual:Upgrading (duplicated at Manual:FAQ) reminds it and says "If you have trouble believing this, read this mailing list post". However, not everyone knows it: I received happy feedback from people surprised by the successfull single-step upgrade from old releases (like, from 1.13 to 1.20) so we can be confident it's true, but how and where should we make it clear? --Nemo 00:11, 21 January 2013 (UTC)
 * Maybe a single-step upgrade is possible, but at least for beginners it is surely not simple at all.
 * See Thread:Project:Support_desk/Easy_way_to_upgrade_from_version_1.8_to_2.1%3F for a daunting example. --88.130.111.240 02:32, 24 January 2014 (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.

How Applying a patch without shell access
Hello,

I have to apply a patch and I don't have shell access.

Do you have some tips to do that ?

Thanks,


 * You can't apply a patch without shell access. The other option is to download the contents to your computer, apply the patch, and upload it again to the server. --Ciencia Al Poder (talk) 10:47, 12 December 2013 (UTC)


 * You can apply patches without shell access: E.g. create a PHP file with something like  <?php exec(patch ...); ?>  in it and call it with the webbrowser. That only needs FTP access to upload the file. --88.130.115.236 03:13, 13 December 2013 (UTC)