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ě)
V případě, že se přeruší podobnou zprávou skripty:

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

Měli byste zkontrolovat, zda jste definovali a  v souboru  (v hlavním adresáři). Jedná se o uživatele a heslo, které tento skript potřebuje pro přístup k databázi.

V některých případech se zdá, že se pro aktualizaci názvu tabulky čte stará proměnná $wgDBmwschema (pro Postgres) místo $wgDBname, i když se používá mysql. Pokud je tomu tak, zbavte se definice $wgDBmwschema v LocalSettings.php.

Co dělat v případě „neočekávané T_STRING“ chyby
Pokud spouštíte update.php z příkazového řádku, může se objevit následující chyba:

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

K této chybě dochází, když je update.php spuštěn z php4.

Ti, jejichž web hostují poskytovatelé, kteří poskytují php4 i php5, by měli provést následující kroky:


 * 1) z příkazového řádku zadejte příkaz 'whereis php5'
 * 2) Jakmile zjistíte umístění cesty php5, vypište obsah adresáře php5/bin
 * 3) jakmile určíte název spustitelného souboru php (php nebo php5), zadejte celou cestu a spusťte update.php

Níže je uveden příklad:

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

Co dělat v případě, že 'registerer_argc_argv je nastaven na false' error
Může dojít k chybě:  Cannot get command line arguments, register_argc_argv is set to false


 * 1) Přejít na ~ / údržba (~/maintenance). Upravte existující soubor „php.ini“ nebo jej vytvořte.
 * 2) Přidejte řádek takto:

 register_argc_argv=true


 * 1) Znovu spusťte php update.php

Webový prohlížeč

 * Viz také 

Pokud je vaše databáze již velká a ve velkém pracovním vytížení, neměli byste používat webový aktualizátor, např. protože se proces aktualizace přeruší, jakmile bude dosaženo maximálního časového limitu. V takovém případě byste měli použít update.php z rozhraní příkazového řádku (nikoli z webu). Co přesně je „příliš velká“, záleží na vašem serveru (např. na jeho výkonu, zatížení a na tom, jak dlouho maximální doba spuštění PHP umožňuje spuštění skriptu). Pokud je vaše wiki příliš velká pro webovou aktualizaci a váš poskytovatel hostingu neumožňuje přístup z příkazového řádku, musíte migrovat wiki na jiný hostingový účet, nejlépe na ten, který má přístup do shellu.


 * 1) Vždy ručně zálohujte wiki před provedením údržby databáze.
 * 2) Navigujte svůj webový prohlížeč do  . Pokud je například vaše wiki na , přejděte na.
 * 3) Vyberte svůj jazyk a klikněte na "Pokračovat" (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. 