Manual:Upgrading/cs



Přenos souboru
Vyberte metodu přenosu souborů:


 * wget
 * Zabezpečená kopie s SCP nebo WinSCP
 * Protokol pro přenos souborů SSH File Transfer Protocol (SFTP)
 * Použití klienta FTP.
 * Hostitelská společnost může poskytovat rozhraní správce souborů prostřednictvím webového prohlížeče. Informujte se u svého poskytovatele.
 * Jiná metoda. Jejich seznam je na List of file transfer protocols

Na začátek
Přečtěte si.


 * 1) Zkontrolujte požadavky
 * 2) Přečtěte si poznámky k vydání
 * 3) Zálohujte stávající soubory a databázi
 * 4) Rozbalte nové soubory
 * 5) Aktualizujte rozšíření
 * 6) Spusťte aktualizační skript a zkontrolujte databázi
 * 7) Vyzkoušejte aktualizaci

Požadavky na kontrolu
MediaWiki vyžaduje:


 * PHP +
 * Jeden z následujících:
 * MySQL + (nebo ekvivalentní MariaDB)
 * PostgreSQL +
 * SQLite +
 * Oracle +

Pokud používáte PostgreSQL, přečtěte si prosím také.

Pro více informací si prosím přečtěte a.

Přečtěte si poznámky k vydání
V distribučním tarballu nebo v souborech rezervovaných / exportovaných z Git existuje řada souborů s velkými názvy souborů, z nichž jeden obsahuje  (wiki). Nyní je čas jej otevřít a zjistit, co se v této verzi změnilo.

Vymazat nevyřešené úlohy
Z důvodu regulace výkonu počítače jsou některé akce v databázi zpožděny a jsou spravovány ve frontě úloh. Tyto úlohy jsou uloženy v databázi a obsahují parametry s informacemi o akcích, které se mají provést. Důrazně doporučujeme spustit tyto čekající úlohy před aktualizací wiki, aby nedošlo k jejich selhání v případě, že by se specifikace parametrů těchto úloh v nové verzi změnila. Pomocí spusťte všechny čekající úlohy a vymažte frontu před provedením aktualizace.

Zálohujte stávající soubory a databázi

 * Úplné pokyny k zálohování jsou zde: 

I když jsou aktualizační skripty dobře udržované a robustní, stále by se cokoli mohlo pokazit. Před pokračováním v aktualizaci databázového schématu vytvořte plnou zálohu wiki, včetně databáze i souborů:


 * obsah wiki z databáze (ujistěte se, že je sada znaků zadána správně, nejprve zkontrolujte LocalSettings.php). Může být dobrý nápad vytvořit výpis XML kromě výpisu databáze SQL.
 * MySQL, výpis SQL i výpis XML se používají pro příkaz :

mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb > file.sql mysqldump --user=wikidb_user --password=wikidb_userpassword wikidb --xml > file.xml
 * PostgreSQL, výpis z databáze pro použití s příkazem :

pg_dump --create -Fc wikidb > file.db.dump
 * SQLite, pro zálohování používáte skript MediaWiki:

php wikifolder/maintenance/sqlite.php --backup-to file
 * obrázky a další mediální soubory (obsah adresáře, vlastní logo /skins/common/images/wiki.png)
 * konfigurační soubory, např.  a   (pokud existuje)
 * Programové soubory MediaWiki, včetně všech vzhledů a rozšíření, zejména pokud jste je upravili.

Použití balíčku tarball
Nové soubory můžete umístit na místo pomocí FTP nebo příkazového řádku. Použijte příkazový řádek, pokud k němu máte přístup! Použití příkazového řádku bude mnohem rychlejší, než kdyby bylo nutné nahrát každý z tisíců souborů přes FTP.

Pomocí FTP nebo graficky
Pokud nemůžete získat přístup k příkazovému řádku na serveru, stáhněte si tarball MediaWiki do místního počítače a pomocí 7zip rozbalte tarball na místním počítači.

Po lokálním extrahování souborů použijte svůj oblíbený FTP klientský software k nahrání adresářů a souborů na server.

Příkazovým řádkem
Možná nemáte příkaz spustit jako, pokud nemáte úplná oprávnění pro zápis do instalačních adresářů wiki u aktuálního uživatele. Když normálně zrušíte rozbalení tarballového balíčku, vytvoří se nový adresář pro novou verzi wiki a budete muset zkopírovat staré konfigurační soubory a adresáře obrázků z vašeho starého instalačního adresáře:

$ cd /path/to/your/new/installation/ $ wget https://releases.wikimedia.org/mediawiki//mediawiki-.tar.gz $ tar -xvzf mediawiki-.tar.gz $ rm mediawiki-.tar.gz

(Open) Uživatelé systému Solaris by měli používat gtar nebo:

$ gzip -dc mediawiki-.tar.gz | tar xf -

Další informace
Po rozbalení tarballu byste měli zkopírovat nebo přesunout některé soubory a složky ze starého instalačního adresáře do nového:


 * , který obsahuje vaše stará nastavení.
 * Adresář  (nebo   ve starších verzích), který obsahuje všechny nahrané soubory na wiki, pokud jste nevybrali jiný adresář pro upload, a nezměníte vlastnictví a oprávnění.   a   (např. pokud je váš webový uživatel apache).
 * Některá rozšíření v adresáři . Vždy byste měli získat aktualizovaná rozšíření! Stará rozšíření nezaručují, že budou fungovat s novější verzí MediaWiki.
 * V případě, že používáte vlastní logo, je třeba tento soubor také obnovit ze zálohy. Před verzí 1.24 obvykle v  . Po verz 1.24 v   nebo  . Potom přidejte do LocalSettings.php např.
 * Vlastní vzhledy z adresáře.
 * Jakékoli úpravy starých instalačních souborů nebo přípon.
 * Jakýkoli soubor .htaccess (pokud používáte Apache a máte v nich definována pravidla).

Po dokončení vytvořte z této nové složky publikovatelnou složku na webovém serveru nebo přejmenujte starý instalační adresář a přejmenujte novou tak, aby odpovídala starému názvu.

Používání Git
Pokud používáte, exportujte soubory do nového prázdného adresáře a zkopírujte staré přizpůsobené soubory do nového adresáře, jak je popsáno v předchozí části.

Pokud upgradujete na MediaWiki 1.25 nebo novější, budete také muset nainstalovat některé externí knihovny PHP pomocí Composeru nebo poskytované kolekce udržované pro farmu Wikimedia. Více podrobností o instalaci a aktualizaci externích knihoven najdete v Dokumentace ke stažení Git.

Použití oprav
Pro opravu menší verze je obvykle k dispozici malý soubor opravy. Ručně stáhněte a rozbalte soubor záplaty z the dumps site nebo postupujte podle pokynů s wget níže. Opravy jsou přírůstkové, můžete vynechat verzi.


 * 1) cd do hlavního adresáře MediaWiki (adresáře s LocalSettings.php).
 * 2) Stáhněte soubor opravy a gunzip.
 * 3) Pomocí   zkontrolujte, co se změní (např., $Patch2)
 * 4) Pokud je vše v pořádku, spusťte znovu patch bez.
 * 5) Zkontrolujte svou Special:Version a měli byste vidět nové číslo verze na místě.

Zbývající soubory, které mohou způsobit chyby
Pokud rozbalíte starý instalační adresář, některé staré soubory mohou způsobit problémy s novou verzí.

Pokud nepoužíváte profiling, ale máte soubor   v kořenové složce MediaWiki, můžete obdržet chyby odkazující na. Odstranění nebo přejmenování souboru  tuto chybu vyřeší. Vzorový soubor $, je také v kořenové složce MediaWiki. Pokud v budoucnu povolíte profilování, může sloužit jako šablona.

MediaWiki 1.23 znehodnocuje mechanismus autodiscovery zobrazení v základních souborech zobrazení. Po upgradu na tuto verzi byste se měli ujistit, že staré soubory,  ,   a   přímo v adresáři   stejně jako odpovídající podsložky uvnitř adresáře   byly odstraněny. MediaWiki bude zaznamenávat varování, pokud se u některého z nich zjistí, že vám pomůže zapamatovat si. (Budete také muset upravit všechny vlastní vzhledy, aby se řídily podobnou konvencí.) Podrobnosti najdete v části Zjišťování $.

MediaWiki 1.24 mění cesty základních souborů skinů. Po upgradu na tuto verzi byste měli zajistit, aby staré soubory,  ,   a   přímo v adresáři   již neexistovaly. Podrobnosti najdete v $objevu.

Aktualizujte rozšíření
Některá rozšíření byla aktualizována, aby fungovala s novou verzí MediaWiki. Ujistěte se, že aktualizujete na nejnovější verze takových rozšíření. Možná budete muset provést ruční aktualizace vlastních rozšíření.

Různé tarballs zahrnují některé podmnožiny rozšíření a mají verze, které vám pomohou aktualizovat výběr toho správného pro vaše hlavní vydání MediaWiki.

Distributor rozšíření funguje dobře pro většinu lidí, kteří chtějí snímek rozšíření, který bude fungovat s jejich podporovanými verzemi MediaWiki.

Pokud chcete více rozšíření, pak je pravděpodobně nejlepší stahování z Gitu. Pokud Git nemáte, ale chcete upgradovat mnoho rozšíření, můžete použít mwExtUpgrader.

Přizpůsobte si LocalSettings.php
Pokud používáte stejné  ze staré verze, možná budete muset přizpůsobit jeho zacházení s novými verzemi:

Registrace zobrazení
Vzhledem k tomu, že v MediaWiki 1.24, seskupená zobrazení, jako jsou Vector, Monobook, Modern a CologneBlue, již nejsou součástí jádra MediaWiki, je třeba je explicitně zaregistrovat do, aby je bylo možné použít, jinak MediaWiki varuje, že nemáte nainstalovaná zobrazení.

Toto, musíte přidat k, když upgradujete ze starších verzí než 1.24 a chcete mít k dispozici jedno z těchto zobrazení:

Tento kód je pro MediaWiki 1.25 a novější. Pro MediaWiki 1.24 musíte použít následující kód:

Další zobrazení nemusí být stále přizpůsobeny novému systému registrace zobrazení, proto si v případě problémů na stránce dokumentace o každé pokožce přečtěte, jak ji správně zaregistrovat.

Registrace rozšíření
Od MediaWiki 1.25 používají rozšíření nový systém rozšíření registrace.

Dříve by vaše místní nastavení $ zahrnovalo něco jako:

Toto lze převést na:

Rozšíření jsou upravena pro použití nového systému registrace rozšíření. Rozšíření, která nejsou přizpůsobena, by měla používat starý způsob jejich instalace. Další informace naleznete v instalačních pokynech na stránce rozšíření.

Ostatní proměnné
Některé proměnné mohou být zastaralé nebo dokonce odstraněny. Mít je v  obvykle nebude mít žádný význam ani účinek. V novějších verzích mohou být přidány nové proměnné nebo některé stávající proměnné změnily jejich typ. Obvykle se pro ně snažíme používat rozumná výchozí nastavení a v případě změny typu musí být zpětně kompatibilní. V každém případě se podívejte na poznámky k vydání a podívejte se na tyto změny.

Spuštění aktualizačního skriptu
Aktualizovat (upgradovat) databázi MediaWiki dvěma způsoby: buď z příkazového řádku nebo z webového prohlížeče. Pokud máte k serveru přístup do shellu, doporučuje se aktualizovat z příkazového řádku, protože se tím snižuje riziko přerušení procesu aktualizace vypršením časového limitu nebo resetem připojení.

Skript se také pokusí stáhnout chybějící související soubory, které MediaWiki potřebuje.

Příkazový řádek
Otevřete příkazový řádek serveru nebo prostředí SSH nebo podobně. K příkazovému řádku se dostanete po připojení k serveru přes SSH. Pokud místní počítač, na kterém pracujete, běží na systému Microsoft Windows, budete potřebovat nástroj jako PuTTY, abyste mohli používat SSH. Z příkazového řádku nebo prostředí Shell přejděte do adresáře  a spusťte skript aktualizace:

$ php update.php Pokud se na serveru Linux objeví chyba, zkuste provést stejný příkaz jako root ( sudo php maintenance/update.php ). Poznámka pro jednoduché instalace ve Windows (např. s ): Nejprve se ujistěte, že je spuštěn váš webový server (například Apache) a databáze (například MySQL). Poté spusťte update.php: klepněte pravým tlačítkem myši, vyberte "Otevřít v" a přejděte do PHP.exe. Výsledné okno příkazového řádku se pravděpodobně dokončí automaticky po dokončení aktualizace schématu.

Může se zobrazit zpráva, že vaše verze PHP je příliš stará a že MediaWiki potřebuje novější verzi. Po této zprávě se aktualizace přeruší. Důvodem této chyby je, že příkazový řádek může použít jinou verzi PHP než verzi, kterou máte, když spustíte MediaWiki z webového serveru. Když se zobrazí tato zpráva, měli byste zkontrolovat, zda můžete spustit novější verzi PHP na shellu pomocí jiného příkazu: Může to být např. být „php5“ nebo „php56“. Pokud je k dispozici jiná verze a - pokud ano - pod jakým jménem, záleží na nastavení vašeho serveru. Pokud to nefunguje, zeptejte se svého hostitele; bude to určitě vědět.

MediaWiki zkontroluje existující schéma a aktualizuje ho tak, aby pracovalo s novým kódem, podle potřeby přidává tabulky a sloupce.

Co dělat v případě chyby „Příkaz ALTER uživateli byl odepřen“ (nebo podobně)
In case the scripts abort with a message similar to:

Error: 1142 ALTER command denied to user 'wiki'@'localhost' for table 'mytable' (localhost) ERROR: must be the owner of the mytable relation

This means that you should check that you have defined and  in your  file (in the main directory). These are the user and password needed by this script in order to access to the database.

In some cases, an old $wgDBmwschema variable (for Postgres) seems to be read for the table name to update instead of $wgDBname, even when mysql is used. If this is the case, just get rid of the $wgDBmwschema definition in LocalSettings.php.

What to do in case of "unexpected T_STRING" error
Individuals running update.php from the command line may encounter the following error:

 syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' \ in ~/maintenance/commandLine.inc on line 13

This error occurs when update.php is run from php4.

Individuals who have their site hosted by providers who provide both php4 and php5 should take the following steps:


 * 1) from the command line, enter the command 'whereis php5'
 * 2) once you have discerned the location of the php5 path, list the contents of php5/bin directory
 * 3) once you've determined the name of the php executable (either php or php5), type in the entire path to execute update.php

Below is an example:

 $ whereis php5 $ ls -la /usr/local/php5/bin $ /usr/local/php5/bin/php update.php

What to do in case of 'register_argc_argv is set to false' error
You may encounter the error:  Cannot get command line arguments, register_argc_argv is set to false


 * 1) Go to ~/maintenance. Either edit an existing 'php.ini' file, or create one.
 * 2) Add a line as follows:

 register_argc_argv=true


 * 1) Re-run php update.php

Web browser

 * See also 

If your database is already big and in high production usage, then you should not be using the Web updater, e.g. because the update process will time out when the maximum_execution_time is reached. In that case you should use update.php from the command-line interface (not from the web). What exactly is "too big" depends on your server (e.g. on its performance, the load and on how long the maximum execution time of PHP allows the script to run). If your wiki is too big for the web updater and your hosting provider does not allow command-line access, then you need to migrate your wiki to another hosting account, preferably to one that does have shell access.


 * 1) Always back up before performing database maintenance.
 * 2) Navigate your webbrowser to  . For example, if your wiki is at , then navigate to.
 * 3) Select your language and click continue.
 * 4) The existing installation should be detected. Follow the instructions on the screen to upgrade it. If asked for the "upgrade key", open your  file and look for the key assigned to.

It might happen that the web-updater does not seem to work: Instead of seeing the initial language selection screen, you might see an empty wiki page, possibly with some error message. In this case it is most likely that your webserver uses Rewrite Rules (most likely for short URLs), which do not show you the updater at mw-config/, but a wiki page at Mw-config/, with capital "M". In this case, rename the .htaccess file for the time of the update. Then you should be able to access the web-updater.

Test the update
Once the upgrade has been completed, browse to the wiki and check that the following operations work as expected:
 * Viewing pages
 * Editing pages
 * Uploading a file
 * Visit Special:Version and check that the version shown is correct and that the extensions are present.

Frequently asked questions


How hard is it to upgrade?
If the only file you have modified is, and you are upgrading from 1.5 or later, the process is very simple. The amount of human work involved is only a few minutes. The database schema changes will take an amount of time proportional to the size of your database — potentially hours for wikis with millions of pages, but for a more typical size of a few thousand pages, it is usually done in seconds.

Minor upgrades, within the same major version, say from 1.13.0 to 1.13.1, do not require any schema changes at all. You can just update the files. The database needs no update, hence it is not necessary to run the installer script.

Upgrading from 1.4 or earlier is potentially complicated because support for character sets other than UTF-8 was dropped, and the schema for storing bulk text changed. Please read the relevant section in the  file.

Upgrading becomes difficult if you have modified our source code, and you don't want your changes to be overwritten. Tools such as diff, patch, Meld or WinMerge may be useful. There is also potential for trouble if you are using unmaintained extensions. Upgrade your extensions at the same time as you upgrade MediaWiki.

If you have modified the skin or use a custom skin you very likely will have to adjust it to work again with the new version of MediaWiki.

How do I upgrade from a really old version? In one step, or in several steps?
It depends: If you are upgrading from MediaWiki 1.4 or older, you should upgrade to MediaWiki 1.5 first. If you are upgrading from a Latin-1 wiki, use upgrade1_5.php (found in MediaWiki 1.5) to convert the relevant parts of the database to UTF-8 ( needs to be set to true in your for this to work). Next, run update.php, and then set the option in LocalSettings.php to the encoding previously used by the wiki (e.g. windows-1252). This is basically how Wikipedia and other Wikimedia Foundation sites were upgraded from MediaWiki 1.4 to 1.5 – see the relevant settings file (warning: huge page!) and some related notes at Wikitech. You may need to upgrade to MediaWiki 1.4 before running the upgrade1.5 script. If you want to make a database dump (e.g. MySQL) of your Latin-1 wiki, make sure the type of the  field in the  table is , not  , to avoid character encoding issues.

If you are upgrading from MediaWiki 1.5 or newer, you can upgrade in one step, from your old version to the latest stable version. The vast majority of reports, as well as automated testing, indicate that doing it in one step works just fine. If you have trouble believing this, read this mailing list post. However, please note that when you update from old versions, chances that you will encounter PHP errors are bigger than when you upgrade from the version directly previous to the new version. You would have received these errors anyway, also if you had not skipped versions, but if you had each time done each single update. Only will you - when you skipped versions - get them all at the same time. This will make the upgrade more difficult, but do not forget that you did not have the trouble updating to the intermediate versions, which you skipped!

Should I back up first?
Short answer: Yes.

Long answer: It depends on a) how much you value your data, b) how hard it is to create a backup and c) how confident you are with MySQL maintenance and administration.

An upgrade failure may leave your database in an inconsistent state, in between two versions. A PHP or MySQL error might happen during upgrade leaving your database partly upgraded. In such situations it may be possible to somehow fix this problem with much manual work. However, it will be way easier to just put a database backup from before running update.php in place and to continue with that. Otherwise you might have hours of - needless - work.

Recovery is often complex. Volunteers on the support forums are unlikely to be impressed if you neglect to make a backup and then need help to recover from upgrade-related corruption. A better outcome is if you can revert to your backup, and then report the bug against the corresponding MediaWiki project in the upgrade process which caused the corruption.

Can I keep my LocalSettings.php?
Yes, but you may have to make some minor changes. The format of is largely backwards compatible. Changes which break LocalSettings.php compatibility will be documented in the "configuration changes" section of the release notes.

Can my wiki stay online while it is upgrading?
Generally yes, however Git may temporarily (for a few seconds) break it.

If you are upgrading between minor releases of MediaWiki, all you need to do is update the source files.

Note: the following assumes you have command line access. If you are upgrading between major releases of MediaWiki, the preferred procedure is as follows:
 * 1) Unpack the new version of MediaWiki into a new directory
 * 2) Prepare that new directory: copy your current LocalSettings.php from the old directory, copy any installed extensions and custom skins (if any). Check  setting in LocalSettings.php and if necessary copy logo file from the old directory to the new directory.
 * 3) In the release notes for the new version, see if any changes need to be made to LocalSettings.php.
 * 4) Place the database in read-only mode by inserting the following variable into LocalSettings.php in the old directory - users will see this message if they attempt an edit during the upgrade process:


 * 1) * This no longer works since MediaWiki 1.27, which also prevents running the update script. A workaround for versions since MediaWiki 1.27 can be found in . See also.
 * 2) Run the update script or the web updater in the new directory.
 * 3) Copy the images from the images sub-directory from the old directory to the new directory.
 * 4) Swap the old directory and the new directory.

Why upgrade?

 * Subscribe to mediawiki-announce to be notified of new releases.

Because it's usually easy enough, a single step from your version to latest and also via web.

Recent releases receive security fixes to keep your wiki and your host safe from vandals, while old releases don't (see ). That makes dozens good reasons to upgrade!

New major releases come with new features, which you might want to use: see the release notes for details. In case you need additional arguments to convince your bosses to let you upgrade from a pretty old version, here is a summary:


 * Since 1.5, edits can be previewed before saving also as diff.
 * Since 1.9, an undo button is available.
 * Since 1.12, patrolling on Special:NewPages is much easier.
 * Since 1.13, you can rename (move) files.
 * Since 1.14, you can fix double redirects automatically.
 * Since 1.16, is available.
 * If you have appropriate caching, since 1.17 optimizes pageload speeds a lot.
 * Since 1.17, category sorting makes sense! (especially for non-English letters); extended to 68 languages after.
 * Since and, users of all languages and genders are correctly addressed by the interface and logs (before 1.15, no gender at all).
 * In the skinning system was reworked making it easier to reuse parts of existing skins in your own skins.
 * Since 1.20, diffs are more readable.
 * In 1.21 and 1.23, email notifications become clearer and more predictable, making your wiki more effective.
 * Since 1.22, vandal fighting (patrolling) is less time-consuming.
 * In 1.24, password storage was improved to allow for better security.
 * Since 1.25, enhanced recent changes are available
 * In 1.26, the "ResourceLoader" mechanism was improved
 * In 1.27, the session management was reworked as well as the user authentication management completely modernized.
 * Since 1.29, the Action API was reworked and improved. Also user group assignments may now be done for a selectable period.

See also the list of the most voted fixed issues on up to 2014.

Also, in MediaWiki 1.18 we started bundling some vital extensions, like a better editor and anti-vandalism tools ConfirmEdit and Nuke; more have been added in later releases. 