Manual talk:Upgrading/Archive 2

Multiple pages on upgrading
This has just been changed back into a redirect with the reason "less work, more up-to-date", however I think this page had a useful purpose, which is more than a simple 'upgrading to the latest version' page can offer.

Is there any objection to re-instating the page as it was?

--HappyDog 13:28, 4 June 2007 (UTC)


 * I would prefer to see the below content integrated into the main Manual:Upgrading page. I tend to agree that multiple pages with overlapping content or goals should be merged and formatted in a more reader-friendly way perhaps if the content is just overwhelming as is.
 * Just my two cents. :)  --Varnent 23:51, 17 December 2011 (UTC)

Setup.php must be included
When i try to run: $ php update.php --aconf ../AdminSettings.php

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

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

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

Call to a member function addMessage on a non-object in
In this release $wgMessageCache is completely removed (see Manual:$wgMessageCache). Extension using this feature doesn't work anymore. Is there any scripts to upgrade extension written using $wgMessageCache?

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

Language Error
My English Sites has Hebrew and Arabic Languages throughout. When I upgraded to 1.15.1 the languages came out looking like this Î•ÎºÎºÎ»Î·ÏƒÎ¹Î± ×”×’×¨×™× ×”×’×¨×™× ×”×ª×•×©×‘×™× ×”×ª×•×©×‘×™× ×”×’×¨×™× ×¢×‘×“ ×§× ××™ ØµØ§Ø¨Ø¦Ø© ØµØ§Ø¨Ø¦ÙŠÙ† Ù…Ø³Ù„Ù… WikiNoah Admin

continue getting error
Hi

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

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

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

can anybody help?

Regards MOh

Hi M0h,

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

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)

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

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

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


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

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

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


 * I'd be happy if someone could explain how to patch on Windows 7. Despite it being POSIX-based it does not contain the patch command or anything similar. In this case I'm running MW on Apache, but I believe the difference is the same for those silly enough to use IIS. Metalbunny (talk) 17:45, 20 September 2013 (UTC)
 * You can get a patch command from cygwin. -- ☠ MarkAHershberger ☢ (talk) ☣ 17:51, 20 September 2013 (UTC)

-As a novice user running a Wiki on a 1and1.com server that I am managing from a Win7 computer, I thought I would put a couple of notes on installing a patch for other novices. You will need to have the following software (or the equivalent) installed on your computer - | Filezilla (for transferring files), | 7-Zip (for opening the .gz compressed file), and | PuTTY (for logging into your server). You'll also need your 1and1 user id for the FTP and SSH log in. You can find this information in your 1and1 admin control panel.Rsoandrew (talk) 18:43, 5 April 2014 (UTC)
 * Download the latest patch file. If you don't get the email updates, look in the news feed on the main MediaWiki page.
 * Extract the patch to your desktop using 7-zip.
 * copy the patch to your wiki's root directory (the one with LocalSettings.php)using Filezilla.
 * SSH into your account using PuTTY and get into the root directory for your wiki.
 * enter the following in the command line (no quotes) modifying the name of the patch file to the one you are using "patch -p1 --dry-run < mediawiki-1.22.2.patch"
 * Review the output. If there are no error, run the same command omitting "--dry-run"
 * Change to the maintenance sub directory and in the command line (no quotes) run "php6 update.php"
 * Go to your special pages and open the version link. You should be updated. Note that if you forget to run update.php, the version page will still report that your version has been updated but things won't work right and you will get database errors.

Upgrading from 1.17alpha to a newer version of 1.17alpha
Are there any difficulties that will occur when upgrading from 1.17alpha to a newer version of 1.17alpha? I have a wiki that I want to keep always on the cutting edge (or close to it) of MediaWiki core development, but I guess this will require frequent upgrades and running of update.php. Would any problems arise in doing that? Tisane 02:59, 26 May 2010 (UTC)
 * I don't think so. I always do the same on my wiki --Diego Grez return fire 03:00, 26 May 2010 (UTC)

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

Occasionally when editing an existing, or authoring a new article I get the following error when either previewing or saving changes: Method not implemented. Post to /w/index.php not supported I use pretty urls which may or may not be relevant. The problem has only appeared since upgrading from 1.16beta3 to 1.16.0. (Although it is just possible that an upgrade to both php and mysql a few days earlier is implicated). I also thought I'd got the trigger when I found that an article exhibiting this problem contained an unclosed 'blockquote' tag and closing it got rid of the error on that article; but it has since happened several times since with no such obvious trigger present.

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


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

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

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

Adding ls_field_val key to table log_search... Ha ocurrido un error de sintaxis en una consulta a la base de datos. La última consulta a la base de datos que se intentó fue: "ALTER TABLE `log_search` DROP PRIMARY KEY, ADD UNIQUE INDEX ls_field_val (ls_field,ls_value,ls_log_id) " desde la función "DatabaseBase::sourceStream". Base de datos retornó error "1091: Can't DROP 'PRIMARY'; check that column/key exists (localhost)". --217.216.40.30 21:55, 8 October 2010 (UTC)


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

mysql> alter table log_search add primary key (ls_field);
 * But my upgrade seems to have failed anyway, so maybe not so helpful :p --170.146.225.4 21:18, 7 February 2012 (UTC)

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)

upgrading from 1.15. to 1.17 stall
I'm trying to upgrade a 1.15 existing mediawiki installation to 1.17. The process stall at

Populating log_search table, printing progress markers. For large databases, you may want to hit Ctrl-C and do this manually with maintenance/populateLogSearch.php.

and no progress. I cannot open a php console to run install.php by command line. Just poor old http... Any hints? --GB 13:46, 31 July 2011 (UTC)

Well, made some investigation and it seems that some (new?) tables are not created, including log_search. I created by hand with phpMyAdmin following table.sql schema and mw started. I'have still problems with my custom skin based on monobook but probably this is not db problem related. I'll check all the table in table.sql against my present db schema. --GB 15:15, 31 July 2011 (UTC)


 * It should be safe to run the installation script multiple times until it finishes. —Emufarmers(T 06:47, 6 August 2011 (UTC)

Upgrading MW. Run update.php - "Cannot redeclare wfgetdb"
Hi,

I've backed up my database, unpacked the tarball into the wiki's current directory. I ran the update.php script from the maintenance directory. And my shell gave me an error (domain name edited out):
 * Cannot redeclare wfgetdb (pre in *path*/includes/DatabaseFunctions.php:50) in /home/*domain*/pubcludes/GlobalFunctions.php on line 3196

70.71.150.1 01:31, 6 August 2011 (UTC)


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

Problems with upgrading from 1.16.5 to 1.17.0
1. GNU diff3 is not found, even though these are specified in LocalSettings.php:

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


 * Iwlinks_table -- says it's 1.17.0 (this caused the error upon submitting edited text)
 * Manual:Module_deps_table -- says it's only the Trunk version
 * Manual:Msg_resource_table -- says it's only the Trunk version
 * Manual:Msg_resource_links_table -- says it's only the Trunk version
 * Hi, we're aware of this problem, see here. Would be great if you added yourself to CC list on that to be able to provide feedback, because we still can't reproduce it. Max Semenik 01:41, 22 August 2011 (UTC)

Fatal Error when upgrading from 1.16.0 to 1.17.0
I recieve this error when the web updater is trying to update my database:

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

How do I fix this? --98.232.245.206 23:13, 27 August 2011 (UTC)
 * Try replacing includes/AutoLoader.php with this. Next time, please ask on Support desk. Max Semenik 06:06, 28 August 2011 (UTC)

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

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

as well as the two corresponding # renamed sequences</tt> lines: //array( 'renameSequence', 'log_log_id_seq',     'logging_log_id_seq'          ), //array( 'renameSequence', 'pr_id_val',          'page_restrictions_pr_id_seq' ),

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

Alternative temporary fix
If update script hasn't been executed yet, simply remove or comment out lines 25 and 26 from //array( 'addSequence', 'logging_log_id_seq'         ), //array( 'addSequence', 'page_restrictions_pr_id_seq' ),

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


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

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

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

from StartProfiler in your root directory.

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


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

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

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


 * You may have added some or even all columns to your database, but the key log_user_type_time is still missing. Running update.php won't fix this, as it only checks for the column "log_user_text" and if that one is there, the patch, which should among other things add this key, is not applied. You can execute
 * ALTER TABLE logging DROP COLUMN log_user_text;
 * Then rerun update.php which should now pick that full patch. --88.130.80.237 12:19, 26 March 2012 (UTC)


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

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

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

Paul

Any plans to automate Upgrading Mediawiki?
There are lots of people I bet that use mediawiki that are not tech savvy enough to perform an upgrade. Are there any plans to automate this process in the future? Would be nice.
 * Seconded! In particular, my shared host has Git access, but only for developer accounts--they don't have it a'la carte, and have told me they don't want to add that feature or a subscription-like feature that would give me the Git access to make updating at least a BIT easier. I think MediaWiki should take a page from Wordpress and find Admin Panel on the Web ways to allow for automatic checking of new versions of MediaWiki and installed, active extensions. --Azurite (talk) 21:07, 14 May 2012 (UTC)
 * That would be difficult without running a bot-like script, because PHP does not work well for things like that. Besides, that would be a big overhead for large wikis that may have more than one server.--Jasper Deng (talk) 21:58, 14 May 2012 (UTC)

Special:SpecialPages
After upgrading from 1.10.1. to 1.18.1 most of the wiki looks fine, but Special:SpecialPages does not show up. The special pages themselves are accessible. Any piece of advice is welcome. --ThT (talk) 10:57, 2 March 2012 (UTC)
 * MediaWiki 	1.18.1
 * PHP 	5.2.14 (apache2handler)
 * MySQL 	5.0.26
 * Updating all extensions did the trick. --ThT (talk) 09:01, 5 March 2012 (UTC)

I have the same problem any advice please


 * This is most probably caused by a PHP error. Activate the error log, if it is not, and then check what PHP wrote to the log after you tried to open this page. --88.130.87.85 15:40, 18 September 2012 (UTC)

Manual Upgrade using CPanel
I went through the process of upgrading from mediawiki 1.15 to 1.18.3 using cpanel only, without shell access and without wget. I had a few problems but nothing major. I documented the experience here at just in case anyone else out there has to use the same process and gets the same errors. Corkipedia

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


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


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


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


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

MediaWiki 1.19.0 update.php stalls at "have page_len field in page table"
Hi, I tried several times to run the MediaWiki 1.19.0 Updater, but it always stalls at "have page_len field in page table". I'm waiting for about half an hour again right now. The database is about 200 MB big. I can't find any problems in my error_log. When I upgraded from MediaWiki 1.18.0 to 1.18.2 everything went pretty fast, so can it really take that long this time? Here is the output of my shell:

MediaWiki 1.19.0 Updater
 * 1) php update.php

Going to run database updates for

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

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

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

Upgrading extensions in a git world (R1.20 and beyond)
Has anyone developed a recipe/strategy for updating their extensions on a production system? Git seems like a starting point, but seems more geared to developers rather than site admins/end users. Special:ExtensionDistributor doesn't show 1.20.x in the release drop-down box. --Peculiar Investor (talk) 15:37, 18 December 2012 (UTC)


 * Well, as usual: Clone it and you have it. Then do a git pull and you do an update. --88.130.81.134 01:57, 19 January 2013 (UTC)

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


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


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


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


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

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

Cannot get command line arguments, register_argc_argv is set to false -- not a simple problem
I have a php.ini file in the same directory as the upgrade.php command that I am trying to run. It contains register_argc_argv=true

The command I am running is: php /home/xxxxx/public_html/mywiki/maintenance/update.php

I have removed the .htaccess file.

The permissions on the php.ini file is 644.

I have tried it with the filename php5.ini

I've tried replacing the php command to php5

What else can I do????

Thanks.

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


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

How Applying a patch without shell access
Hello,

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

Do you have some tips to do that ?

Thanks,


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


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

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

PLEASE HELP.


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


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