Manual talk:Upgrading/Archive 2

Multiple pages on 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)

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)

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

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.


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

Applying a Security Patch
The Patch from 1.21.1 to 1.21.2 gives errors on the dry run [command: patch -p1 --dry-run < mediawiki-1.21.2.patch]. The errors, however, are all specific to a couple of files being updated in a tests folders which doesn't exist on my installation. Specifically the errors are related to updating:
 * tests/phpunit/includes/libs/IEUrlExtensionTest.php
 * tests/phpunit/suite.xml
 * tests/TestsAutoLoader.php

and of course I also get .rej file write errors since I don't have the test folder for the files to be written to. It seems to me that I can safely apply this patch and ignore the errors but if anybody has any other thoughts on this I wouldn't mind hearing them Rsoandrew (talk) 06:48, 22 September 2013 (UTC)


 * Yes, you can safely ignore anything from the  folder, since it's only used by developers. --Ciencia Al Poder (talk) 17:59, 22 September 2013 (UTC)

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)

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

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)

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)


 * You can update a wiki without shell access (SSH). To do that extract the new files on your PC and upload them via FTP. New versions of MediaWiki ome with a web updater in my-domain.com/path-to-wiki/mw-config/index.php. Then run this web updater with your browser. This allows you to update the database with your webbrowser. --88.130.87.85 15:34, 18 September 2012 (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 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.
 * 178.183.191.232 22:51, 8 July 2011 (UTC)


 * NOTE: This error message is a sign that the extension php_mysql.dll is not loaded. I had this while migrating to a new version on a new server which had only php_pdo_mysql.dll enabled. You should check your php.ini/ phpinfo if you get this error.

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)

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:

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)

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)</tt>). 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)

from StartProfiler in your root directory.

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)


 * just ran into this problem as well after upgrading from debian squeeze to wheezy. The fix is to execute the following
 * CREATE INDEX /*i*/log_user_type_time ON /*_*/logging (log_user, log_type, log_timestamp);
 * as seen in /usr/share/mediawiki/maintenance/archives/patch-log_user_text.sql

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. Any piece of advice is welcome. --ThT (talk) 10:57, 2 March 2012 (UTC)
 * MediaWiki 	1.18.1
 * PHP 	5.2.14 (apache2handler)
 * MySQL 	5.0.26
 * Updating all extensions did the trick. --ThT (talk) 09:01, 5 March 2012 (UTC)

I have the same problem any advice please


 * This is most probably caused by a PHP error. Activate the error log, if it is not, and then check what PHP wrote to the log after you tried to open this page. --88.130.87.85 15:40, 18 September 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 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)


 * It is not only images/, but also extensions/ and skins/ (people might have modified a skin or use a custom skin).


 * And LocalSettings.php must be kept. ;-) --88.130.73.142 21:46, 25 July 2012 (UTC)


 * I also got an error that /includes/ was missing, so I had to copy it also. Saariko (talk) 13:14, 25 July 2012 (UTC)


 * When you are doing an update, the files in the folder includes/ have to be replaced with the new files as well. Or with other words: You must extract all files from the new package and replace the old files with them. This includes the files and folders in the folder includes/. --88.130.73.142 21:48, 25 July 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:

MediaWiki 1.19.0 Updater
 * 1) php update.php

Going to run database updates for

I use PostgreSQL, but except for the schema this could apply for other databases, as well. 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)

Command Line (done)
I'm a complete novice at this. I've placed all the new files onto the server in the correct folders etc, all I need to do is run the update. I doesn't work using the web method, so the only other method is via the Command Line. For the love of god, why doesn't this thing tell me where to FIND this command line, because I can't find one anywhere. Where am I meant to be looking?


 * The commandline is a kind of "interface" to your server. There are several ways to communicate with a server. When you say that you uploaded all the MediaWiki files to the server, you most probably did that using FTP. Another way to communicate with your server might be not via FTP, but via SSH. An SSH connection is not offered by all hosting providers; possibly you do not have SSH access available. If SSH is offered, then this is an alternative way to connect to your server. If your home PC, from which you are working right now, runs MS Windows, you need an additional tool to use SSH. This tool is called Putty. With Putty you can then connect to your server using SSH. Then you will see the command line.


 * Usually the command line looks like a small black window with some white text in it. In the last line there is a blinking cursor and there you can type commands, which are then executed. So if you connect to your server via SSH, you can then run commands directly on the server. You type them in this small black window and they are executed on your server.


 * PS I have just added according hints to the page. :-) --88.130.102.160 13:47, 25 November 2012 (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)

Make page translatable
According to stats, this seems to be the 24th most visited page of the wiki. I'd like to make it use the Translate extension, but I need two things. Volunteers? --Nemo 16:58, 17 January 2013 (UTC)
 * 1) someone to check it's actually current and well written (hence stable enough),
 * 2) someone to import the old translations in the new system quickly when it's marked for translation.


 * For the first point: There were some small changes to the page content, but that is usual for such an important page and won't be avoidable. However, all in all the content has not changed drastically in the last 6 months or so. I guess that must be stable enough.
 * For the second point I don't think I can help as an IP... ;-) --88.130.81.134 01:57, 19 January 2013 (UTC)


 * The page has been static, sure, what I wonder is if it will need to be rewritten or is reasonable that current text will survive.
 * Actually you can: translation is open to all. You could also prepare it for translation, but I can do it for you. ;) Let me know, Nemo 06:21, 19 January 2013 (UTC)


 * If you always want to wait as long as things might possibly be changing, you will actually never start. Future will bring what the future will bring; and who can see in the future? ;-)
 * I don't know how translation is thought to be done - having the English texts for the average user is rather fine, don't you think? :-) --88.130.95.173 07:01, 19 January 2013 (UTC)


 * No, I don't think so. ;-) We have already 13 translations in unknown state for this page; this is how it is thought to be done. --Nemo 07:16, 19 January 2013 (UTC)
 * Ok, then go ahead. ;-) --88.130.95.173 21:12, 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.

"you need to migrate your wiki to a hosting account that does have shell access" (done)
Ah, so casually stated.

This is simply not an option for many, and hopefully is a last resort rather only after all other options have failed. I would hazard that the majority of hosting services do not provide shell access, and with good reason. Also, the majority of wikimedia "administrators" are not techies or developers - to them wikimedia is just another app like Word or Wordpress, and this also is as it should be. In depth technical knowledge should not be required for something as simple as upgrading an application.

If the web interface has limitations, it would be good to at least to attempt to spell those out in detail: Of course there are many variables, but any clues at all would help. Roughly how big is too big? What do you measure to at least get an estimate? How to get around this if you are worried that it might be a problem? I.e., "Go into cpanel, Go to PHP Settings and and set your max_execution_time to ???" if that's what would help (I'm totally just guessing). If running as a cron job is an option, say so, and spell out how. If there are reasons this will not work, let people know.

I don't know the answers myself or I would write these hints. But "you need to migrate your wiki" strikes me as a lot less than helpful.


 * I have updated the page accordingly, however, in the situation described on the page there is no way around using SSH: If you have a big wiki and a poor host, then it's just likely that things don't work as expected. The web updater is just not made for you then. Yes, it would work, also with big databases, but to get it working, you will need to adjust some PHP settings, like the maximum execution time. Which shared hoster, which does not even give you shell access, will allow you to do so? Maybe when you pay extra, but why don't you instead pay to get reasonable hosting - including SSH access? That would solve you way more problems. Btw: A few versions ago, there was no web updater at all. You were just forced to use SSH in any case. If you didn't have it, you could just not update at all. Compared to this, the current situation is a vast improvement, don't you think? --88.130.90.136 11:49, 4 July 2013 (UTC)

help me please

 * 1) i tried to upgrade mediawiki 1.16.x to 1.21.
 * 2) i using a apache webserver and mysql.
 * 3) when i upgrading, a database was changed, and i didn't backup mysql db
 * 4) it looks like great but..
 * 5) i see a some problems so i decided a roll back mediawiki.
 * 6) so i replace old mediawiki php files to mediawiki directory and run again 'mw-config'
 * 7) and then, a mediawiki was cracked.
 * 8) when i roll back to 1.16x, a site didn't showed up portal and showing up 'fatal error' :
 * 9) Fatal error: Call to undefined method MediaWiki::run in C:\xampp\htdocs\mediawiki\index.php on line 59
 * 10) when i roll back to 1.21, apahce webserver demon crashing.
 * 11) i'm most afraid in my database. it's a company's archive. oh. my. god.
 * 12) help me please


 * MediaWiki updates are not backward-compatible in a way that you could switch back to an older version, run the older updater and get a functional DB again. The old updater does not know what changed in the newer versions and there also is no code, which would turn back those changes.
 * When you want to go back to an older version of MediaWiki, you will always have to do that by importing a backup, otherwise you have no guarantee that things will continue working.
 * MySQL does have some sort of rollback function, but, if it is activated and not switched off, it only works for a certain amount of commands. The longer you continue using your database the more likely the commands, which were done during the update, will no longer be in the log and you won't be able to go back. Should you want to go that way you should ask an expert, before you possibly loose precious data.
 * Maybe it works, when you go to MW 1.21, run the updater again and then see what you get. Given that you do not have a backup of which you know that it's working, I think your database should then be in the best state you can get. Should Apache be crashing again, look into the Apache error log and see, what it says. --88.130.90.136 11:59, 4 July 2013 (UTC)

Inconsistent states
"It may move an important table to a temporary name and then fail before it recreates the table correctly. It may change a field definition to an incorrect data type." Are the scripts not designed to detect and fix these problems? If so, is there any reason not to write them to be more robust, in which case there should something filed in Bugzilla? Leucosticte (talk) 23:58, 7 November 2013 (UTC)


 * Those scripts are designed to upgrade the database based on the history of changes of the schema, detecting if fields or tables exist or not. Measuring the robustness of such scripts may not be trivial, and of course they may eventually fail if the database was modified by hand or the user attepts to do a downgrade, or partial upgrades stopped by a database failure (database corruption, insufficient disk space, etc). Having said that, I don't see a point in filing a bug about this without a specific example and reproducible steps, otherwise it would never be fixed. Bugs may happen and should be reported when detected. --Ciencia Al Poder (talk) 11:03, 8 November 2013 (UTC)

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)

upgrade wiki1.22.4
Hi, I'm in the process of upgrading a wiki site. I followed the steps mentioned in this site and I wonder if I'm doing something wrong. I used FileZila for transfering the uncompressed files of MediaWiki to the FTPserver, but looks the process takes too long: out of about 7500 files, its now 6 hours that only about 4200 files passed to the FTP, and about 340 file were droped and didn't pass through. Is this the right speed? should I do something different?

PLEASE HELP.


 * That highly depends on your upload speed and the server's download speed. If you're uploading files directly over the old installation, that may slow down the process, because you need to (auto)confirm the overwrite of old files for each one. Also, upgrading over the old files is not recommended, unless you're upgrading from the same major version. --Ciencia Al Poder (talk) 10:37, 24 March 2014 (UTC)


 * And upgrading by extracting the MediaWiki tarball directly on the server will be much faster! --88.130.89.88 10:51, 25 April 2014 (UTC)

Updating a file (done)
After updating a file in my wiki, do I have to run update, in order that the change will be active?


 * What do you mean by updating a file? Do you mean editing a PHP file? In that case, no, you don't need to run update.php. That script is for schema changes --Ciencia Al Poder (talk) 10:11, 5 April 2014 (UTC)
 * update.php only needs to be run after you installed something in your wiki: That can be a new MediaWiki version or a new extension. In case of a MediaWiki update, you need to run update.php after a major update (like from 1.22 to 1.23). When you did a minor update (like from 1.22.6 to 1.22.7), then you do not need to run update.php. However, the article already says that. --88.130.89.88 10:45, 25 April 2014 (UTC)