Manual talk:Upgrading

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)

Error

Setup.php must be included

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

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

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

Can't create table

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

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

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

Any answer to this?

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

No SSH shell available

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

so, how can I update the database?

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

Language Error

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

continue getting error

Hi

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

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

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

can anybody help?

Regards MOh

Hi M0h,

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

This script must be run from the command line

cant run the upgrade script from firefox

INDEX command denied to user

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

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

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

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

so what gives?

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

---

212.251.167.205 20:48, 13 October 2010 (UTC)

Where do you come from?

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

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

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

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

Applying a patch

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

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

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

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

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

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

Upgrading from 1.17alpha to a newer version of 1.17alpha

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

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

Upgrading DB

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

-- 18 June 2010

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

Method not implemented error

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

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

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

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

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

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

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

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

Upgrade - How?

Dear MediaWiki readers.

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

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

- Mikkel Trebbien, Denmark.

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

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

MW 1.16 Upgrade From 1.15

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

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

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

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

Going to run database updates for wikidb

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

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

Any help appreciated!

Two things:

First: Make sure that you have copied all files of the new MediaWiki version into place. The updater still tells you that you use version 1.15.1, while you say you want to upgrade to 1.16.

Second: The message "Comments starting with '#' are deprecated" is caused by line 1 in /etc/php5/cli/conf.d/mcrypt.ini. This line starts with a "#" sign, but that is deprecated. Comments should always start with a ";" sign instead. --88.130.87.85 15:28, 18 September 2012 (UTC)

1091 mysql error

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

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

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

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

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

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

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

Update multiple wiki instances

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

I don't know if there is a way to update all in one go. However, updating the seperately should work at least. --88.130.87.85 15:30, 18 September 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#Run the update script

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

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

See includes/LocalisationCache.php

...relation "msg_resource" does not exist

 See includes/MessageBlobStore.php

All need SCHEMA reference for postgreSQL.

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

undefined function mysql_error()

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

MediaWiki 1.17.0 Updater

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

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

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

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

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

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

Hi,

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

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

70.71.150.1 01:31, 6 August 2011 (UTC)

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

Problems with upgrading from 1.16.5 to 1.17.0

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

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

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

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

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

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

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

Fatal Error when upgrading from 1.16.0 to 1.17.0

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

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

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

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

PostgreSQL schema update errors (1.15 -> 1.17)

Problem

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

Temporary fix

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

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

as well as the two corresponding # renamed sequences lines:

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

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

Alternative temporary fix

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

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

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

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

Suggestion

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

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

---

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

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

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

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

Skin Error upgrading from 1.16.5 to 1.18.1 (tooltipAndAccesskey)

I received the following error:

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

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

solution

Replace it with tooltipAndAccesskeyAttribs

Frank

---

That worked for me too!

Rudolf

Delete config and mw-config for security???

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

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

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

Test

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

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

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

"Cannot redeclare wfprofilein()"

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

"Cannot redeclare wfprofilein()"

then remove

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

from StartProfiler in your root directory.

php update.php returns nothing and system not upgraded.

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

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

Problems upgrading from old version

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

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

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

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

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

ALTER TABLE logging DROP COLUMN log_user_text;

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

Newbie Upgrade Help

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

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

wfrunhooks error when upgrading from 1.15 to 1.18

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

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

Paul

Any plans to automate Upgrading Mediawiki?

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

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

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

update.php

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

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

Use

cd wiki/maintenance

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

php update.php

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

Special:SpecialPages

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

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

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

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

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 [1] just in case anyone else out there has to use the same process and gets the same errors.

Corkipedia

Which files to copy from the old installation?

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

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:

# php update.php
MediaWiki 1.19.0 Updater

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

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

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

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

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

Big databases on a shared host

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

The problem is that the time an update needs roughly grows proportionaly with your database size.

That means: If you run the web installer and have a "big"ger database, you are more likely to run into a timeout than with a smaller size.

So: What is too big, cannot be said generally. It depends on factors like

• your maximum execution time
• the load on the server
• the speed of the server

--88.130.94.243 22:53, 16 June 2012 (UTC)

Upgraded then got Blank Pages

I upgraded from 1.17 to 1.19, making sure that PHP and MySQL were also at proper versions. Everything seemed to go well, until I went to check on the wiki itself. All I get now are blank pages, can not load anything! I have removed any extensions that I had in hopes that one of them was breaking the wiki. No luck. What else should I do?

Activate errorDisplay in PHP to see what's going wrong. Alternatively you should be able to get the same info by checking the PHP error log. --88.130.97.249 01:58, 25 July 2012 (UTC)

I have the same problem, after upgrating from 1.16 to 1.19.2. The PHP error log shows nothing. Any other ideas? 15:05, 26 October 2012 (UTC)

Try to delete or rename the StartProfiler.php

I have the same problem from updating 1.15.1 to 1.20.3. The Main Page does not load after the upgrading process (which runs without errors). I tried to rename StartProfiler.php, but that does not help. Do you have any other suggestions? It's an important wiki for us. Please, help! Csega (talk) 14:24, 23 March 2013 (UTC)

Activate errorDisplay in PHP to see what's going wrong. Alternatively you should be able to get the same info by checking the PHP error log. --88.130.90.169 22:54, 23 April 2013 (UTC)

Upgrade from 1.7 to 1.19 left the wiki open for edits to anyone=

I upgraded aging install that had trouble after upgrade of php to 5.3 and after that all pages were editable by anyone without login. This should be noted in the upgrade instructions.

I guess this is caused by a misconfiguration in LocalSettings.php. Maybe the format of the according settings also changed sometime between 1.7 and 1.19; if this is the case I think this is already documented nicely. --88.130.97.249 01:59, 25 July 2012 (UTC)

Update without using update.php or web-installer

I want to know, how I can update my wiki using SQL patch files directly. --IKlim (talk) 06:06, 6 July 2012 (UTC)

Long answer short: You cannot.

Maybe you can use the SQL files, which you get with your MediaWiki package, to add some fields or indeces, but note that they are for different database management systems. If you want to apply them by hand, make sure that you take the correct ones or you will likely break your system! However, the new fields/tables in some cases need to be filled with some content before you can use them and this is done by the Updater (update.php or the web interface). E.g. when you update to 1.19 a SHA hash is calculated for each revision. I don't see a realistic way of doing things like this without using the updater. --88.130.97.249 02:04, 25 July 2012 (UTC)

You can do it by hand (the relavent files are in maintinance/archive directory), however its the type of thing that if you have to ask the question, you probably shouldn't be doing it by hand (Very large wikis for example sometimes have to do special things in order to do live updates while having heavy load, really that's the only reason to do it by hand). For things like the SHA-1 hashes of revisions, there are maintinance scripts independant of update.php that can be run. Similarly sql.php will fill in the fields of the sql files provided with MediaWiki. But really, unless you have a good reason not to use update.php, use update.php. Bawolff (talk) 13:40, 25 July 2012 (UTC)

If you do not want to run a script like update.php, I think running another maintenance script the same way also is not really an option. It all comes down to using update.php... --88.130.87.85 15:01, 18 September 2012 (UTC)

PHP Fatal error DatabaseMysql.php on line 305

I am trying to install Extension:AbuseFilter

MySQL : 5.1.60

php_version： 5.3.12

nginx/1.0.14

root@zoglun:/wiki/maintenance# php update.php
MediaWiki 1.19.0 Updater

PHP Fatal error:  Call to undefined function mysql_error() in /wiki
/includes/db/DatabaseMysql.php on line 305

--Zoglun (talk) 22:29, 29 July 2012 (UTC)

I received the same error message as Zoglun--also referring to line 305--after having run update.php during ConfirmAccount extension set-up. I'm not sure what to do, or how serious a problem this is. I'd like to learn more, or fix the problem, if by chance anyone can provide a detailed explanation. Like, what is that mysql_error() function supposed to do?

VERSION INFO -

MediaWiki 1.19.1, PHP 5.3.8 (apache2handler), MySQL 5.5.16

ERROR MESSAGE -

MediaWiki 1.19.1 Updater Fatal error: Call to undefined function mysql_error() in ... includes/db/DatabaseMysql.php on line 305

--Magic Sands

I'm also receiving the same error trying to run update.php after installing the TitleKey extension.

MediaWiki 1.19.2, PHP 5.4.4 (apache2handler), MySQL 5.5.25a

--wiiittttt

If you have MySQL enabled, mysql_error() will be defined 100% of the time (unless it is disabled through the disable_functions PHP directive but I doubt that is the case).

So it sounds like the MySQL extension is not loaded. Are you sure you are using PHP5.3 or 5.4? It is possible that you have another PHP versions, when you run a script from the shell than when you call the wiki with your browser. Some hosters have the PHP5 executables available on the shell as "php5". You could try running "php5 update.php".

If you are running a PHP version, which should work, but get this error anyway, MySQL needs to be enabled in php.ini. --88.130.87.85 15:47, 18 September 2012 (UTC)

No Display Skin after upgrade 1.15.4 to 1.19.1

www.waihekepedia.org

After runnning the tarball extract, update.php and renaming profiler the site comes up without a theme and no side panels or tab layout.

Including the new vector.php in local settings has no effect. The logo that was pathed doesn't apear and changing the $wglogo to a known path makes no change, no visible logo. Its as if the default skin is completley blank.

Any ideas please ?

Please check your $wgServer value. If it is not www.waihekepedia.org then you need to change it to that.--Jasper Deng (talk) 22:03, 22 August 2012 (UTC)

Thanks for the early reply, I set $wgServer to the URL directly in Localsettings, its there now, no difference. I found this thread http://www.mwusers.com/forums/archive/index.php/t-17498.html but its about the monOskin, and 1.19 uses vector apparently. I'm actually quite confused about where to put the side bar and other eidts as some are appearing just below the wiki iteslf, but no wiki tabs to me is an issue apart form the side bar and other extensions such as googlemaps that arent appearing either..

I had these same symptoms after migrating to another server, and it was caused by bad permissions on the 'load.php' file (couldn't have group write permissions). I got the clue from the server error log - it's definitely worth checking the error logs for this. Kyloma (talk) 04:38, 18 December 2012 (UTC)

Debian 7 (Wheezy) upgrade had this, too. (Debian mediawiki 1:1.19.5-1 )

I had to create TABLE "module_deps" (and INDEX "md_module_skin"):

CREATE TABLE mediawiki.module_deps (
   md_module  TEXT  NOT NULL,                                                      
   md_skin    TEXT  NOT NULL,                                                      
   md_deps    TEXT  NOT NULL                                                     
);
CREATE UNIQUE INDEX md_module_skin ON mediawiki.module_deps (md_module, md_skin);
 
GRANT ALL ON ALL TABLES IN SCHEMA mediawiki TO wikiuser;

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:

ERROR:  relation "module_deps" does not exist at character 74

From /etc/mediawiki/LocalSettings.php:

$wgDBtype           = "postgres";
$wgDBmwschema       = "mediawiki";
$wgDBuser           = "wikiuser";

hbswn (talk) 21:04, 22 May 2013 (UTC)

Internal error going from MW-1.19.2 to MW-1.20

Hello. We have a strange problem. After upgrading from 1.19.2 to 1.20 this morning we get the following messages below on our wiki when trying to open most File:Filename.png pages. It happens on most files but not all.

On top:

Notice: Undefined offset: D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\ImagePage.php on line 361

On the page itself:

Internal error

No width specified to ImageHandler::makeParamString

Backtrace:

#0 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\filerepo\file\File.php(795): ImageHandler->makeParamString(Array)
#1 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\filerepo\file\File.php(777): File->generateThumbName('Learning_curve....', Array)
#2 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\filerepo\file\File.php(887): File->thumbName(Array)
#3 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\ImagePage.php(590): File->transform(Array)
#4 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\ImagePage.php(369): ImagePage->makeSizeLink(Array, NULL, NULL)
#5 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\ImagePage.php(149): ImagePage->openShowImage()
#6 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\actions\ViewAction.php(37): ImagePage->view()
#7 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\Wiki.php(427): ViewAction->show()
#8 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\Wiki.php(304): MediaWiki->performAction(Object(ImagePage))
#9 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\Wiki.php(536): MediaWiki->performRequest()
#10 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\includes\Wiki.php(446): MediaWiki->main()
#11 D:\Program Files\Apache Software Foundation\Apache2.2\htdocs\InternalWikiTest\index.php(59): MediaWiki->run()
#12 {main}

I will test further on a Copy of our site to see if I can find the cause.

We upgraded before without any problems but for now we reverted back to MW-1.19.2.

Configuration

• OS Server 2003
• MediaWiki 1.20.0
• PHP 5.3.8 (apache2handler)
• MySQL 5.5.19

--Jongfeli (talk) 10:04, 7 November 2012 (UTC)

Short update. When your wiki runs with non defaults for $wgDefaultUserOptions['thumbsize'] this can happen. See bug 41878 for details. --Jongfeli (talk) 12:43, 8 November 2012 (UTC)

Command Line

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)

maintenance/update.php: Command not found

I can't run update.php with Putty. What's wrong here?

www.abcde123593.com> maintenance/update.php

maintenance/update.php: Command not found.

www.abcde123593.com> maintenance/update.php

maintenance/update.php: ?php: cannot open

maintenance/update.php: /bin: cannot execute

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: you: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: COPYING: not found

maintenance/update.php: either: not found

maintenance/update.php: syntax error at line 11: `*' unexpected

--79.218.195.57 21:23, 26 November 2012 (UTC)

You are using the command line incorrectly. :-) You basically always have to type in a command and then one or multiple arguments.

On the commandline use "cd" commands to change to the maintenance directory. For example if you are in the root of your MediaWiki installation:

cd maintenance

Before doing a "cd" command you can always use the "ls" command to see the contents of the folder you are currently in:

ls

When you are in the folder "maintenance", use the php interpreter to execute update.php:

php update.php

Possibly this will give you an error "Command not found". Then try using "php5" instead of "php" like so:

php5 update.php

--88.130.75.225 13:19, 28 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#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)

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.

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.

Volunteers? --Nemo 16:58, 17 January 2013 (UTC)

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#How do I upgrade from a really old version? In one step, or in several steps? (duplicated at Manual:FAQ#Upgrading) 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)

1.19.3 update to 1.20.2 failed - Error: invalid magic word 'speciale'

Hi.

I've just tried updating an en 1.19.3 wiki to 1.20.2. I'm getting the following error:

Error: invalid magic word 'speciale'

Backtrace:

#0 /var/www/webapps/store/includes/MagicWord.php(236): MagicWord->load('speciale')
#1 /var/www/webapps/store/includes/parser/Parser.php(4765): MagicWord::get('speciale')
#2 /var/www/webapps/store/includes/parser/CoreParserFunctions.php(74): Parser->setFunctionHook('speciale', Array)
#3 /var/www/webapps/store/includes/parser/Parser.php(253): CoreParserFunctions::register(Object(Parser))
#4 /var/www/webapps/store/includes/cache/MessageCache.php(829): Parser->firstCallInit()
#5 /var/www/webapps/store/includes/cache/MessageCache.php(807): MessageCache->getParser()
#6 /var/www/webapps/store/includes/Message.php(618): MessageCache->transform('$1 - {{SITENAME...', true, Object(Language), Object(Title))
#7 /var/www/webapps/store/includes/Message.php(436): Message->transformText('$1 - {{SITENAME...')
#8 /var/www/webapps/store/includes/Message.php(476): Message->toString()
#9 /var/www/webapps/store/includes/OutputPage.php(790): Message->text()
#10 /var/www/webapps/store/includes/OutputPage.php(833): OutputPage->setHTMLTitle(Object(Message))
#11 /var/www/webapps/store/includes/Article.php(485): OutputPage->setPageTitle('Main Page')
#12 /var/www/webapps/store/includes/actions/ViewAction.php(37): Article->view()
#13 /var/www/webapps/store/includes/Wiki.php(427): ViewAction->show()
#14 /var/www/webapps/store/includes/Wiki.php(304): MediaWiki->performAction(Object(Article))
#15 /var/www/webapps/store/includes/Wiki.php(536): MediaWiki->performRequest()
#16 /var/www/webapps/store/includes/Wiki.php(446): MediaWiki->main()
#17 /var/www/webapps/store/index.php(59): MediaWiki->run()
#18 {main}

I followed the upgrade instructions as usual and have run update.php.

Any ideas? --Mitchelln (talk) 14:29, 6 February 2013 (UTC)

Upgrading 1.19 to 1.20

I changed all variable php.ini, and I changed in LocalSettings to $wgUpgradeKey=true;

Error A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: https://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: SELECT page_title,old_text,old_flags FROM `Viquipage`,`Viquirevision`,`Viquitext` WHERE page_is_redirect = '0' AND page_namespace = '8' AND (page_title NOT LIKE '%/%' ) AND (page_latest=rev_id) AND (rev_text_id=old_id) AND (page_len <= 10000) Function: MessageCache::loadFromDB(en)-small Error: 1146 Table 'wiki.Viquitext' doesn't exist

and I changed permissions of update.php to 777 and the folder maintenance to 777

and the error

You don't have permission to access /mediawiki2/maintenance/update.php on this server.

Why?

Hi!

Some things: Do not set $wgUpgradeKey=true, but to a string instead. This string should be un-guessable. I do not know why you changed php.ini files; generally that should not be needed. You should run maintenance/update.php, possibly from the command line. After setting 777 permissions that should be possible. However, the right way would be to fix the owner and group of your MediaWiki folder so that your user account can access them without 777 settings. And then fix these settings again, maybe to 750 for folders and 640 for files or so, 640 for LocalSettings.php. --88.130.83.34 00:19, 22 March 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.