Manual talk:Upgrading/Archive 1

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)

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)

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)

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)

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)

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)

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 (which you might want to do for several reasons, e.g.because you installed a new extension). --88.130.80.237 12:27, 26 March 2012 (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)

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

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

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)

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)

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

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)

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)

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

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)

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)

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

The page does no longer seem to be accessable - at least it is not right now. --88.130.83.67 11:14, 29 April 2014 (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.

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)

I have described that error on page Manual:Load.php. See there! --88.130.77.56 04:43, 26 January 2014 (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)

"you need to migrate your wiki to a hosting account that does have shell access"

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)

Updating a file

After updating a file in my wiki, do I have to run update, in order that the change will be active? — Preceding unsigned comment added by Noham100 (talk • contribs)

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)

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)

Now codumented in section "Unpack the new files" -> "Other files". --88.130.83.67 11:14, 29 April 2014 (UTC)

Uploading files with FTP

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. — Preceding unsigned comment added by Noham100 (talk • contribs)

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! This should still be added in the article! --88.130.89.88 10:51, 25 April 2014 (UTC)

I have just added that to the article. --88.130.83.67 11:24, 29 April 2014 (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)

It is true that the DB upgrade may fail leaving the DB in inconsistent state, but I don't think the exact situation described here fits really well. I guess saying that you can get a PHP or MySQL error during upgrade would be better. --88.130.83.67 11:14, 29 April 2014 (UTC)

I just fixed that. --88.130.83.67 11:29, 29 April 2014 (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)

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? for a daunting example. --88.130.111.240 02:32, 24 January 2014 (UTC)

I have just relativized wording on single-step-update. Obviously it is - especially for beginners - _not_ easy to update in only one step. --88.130.83.67 12:23, 29 April 2014 (UTC)