Manual talk:Upgrading/Archive 2

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?

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

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

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)