Testovací kopie WordPressu: bezpečná aktualizace se zálohou

WordPress se bezpečně aktualizuje jen v pevném pořadí: zálohuj soubory i databázi, tu zálohu obnov do druhé kopie webu, udělej aktualizace tam, projdi stránky, které vydělávají peníze, a teprve potom stejné aktualizace zopakuj na ostrém webu. Pátý krok, který většina návodů vynechává, je ověřit, že se záloha vůbec obnoví. Pokud jako cíl obnovy použiješ testovací kopii, kroky dva a pět jsou jedna a ta samá akce a celý postup tě stojí asi dvacet minut měsíčně. Zbytek článku je ten postup podrobně: příkazy, konstanty v wp-config.php, které kopii brání chovat se jako originál, a chyby, kvůli kterým je „test“ k ničemu.

Proč aktualizace rozbíjejí weby na WordPressu#

Web na WordPressu je jádro, šablona a hromada pluginů od různých autorů, které běží na jedné verzi PHP nad jednou databází. Aktualizace změní jednu z těch částí a neví, co dělají ostatní. Většina aktualizací projde bez potíží. Ty, které bolí, spadají do čtyř skupin:

• Plugin volá něco, co nové jádro odstranilo nebo označilo za zastaralé, a stránka, která to používala, ukáže fatální chybu nebo prázdnou obrazovku. Příznaky a řádky logu jsou popsané v článku bílá obrazovka a chyby 500 ve WordPressu.
• Aktualizace pluginu změní tabulky v databázi při prvním načtení. Je to změna jedním směrem: vrácení starých souborů pluginu nevrátí starou strukturu tabulek.
• Aktualizace šablony přepíše tvoje úpravy. Cokoli jsi změnil ve složce nadřazené šablony, zmizí a nikdo tě předem nevaruje. Podřízená šablona (child theme) existuje právě proto, aby se to nestalo.
• Změna verze PHP není aktualizace WordPressu, ale často jde spolu s ní. Plugin, který běžel na 8.2, může na 8.4 hlásit varování nebo padat.

Podle seznamu změn nepoznáš, do které skupiny aktualizace patří. Zjistíš to tak, že ji pustíš někde, kde na výsledku nezáleží. To je celý důvod pro testovací kopii a také důvod, proč „aktualizuju v klidné noci“ není plán: klidná noc nezpůsobí, že rozbitá stránka s pokladnou bude méně rozbitá, jen si toho všimne méně lidí dřív než ty.

Postup v šesti krocích#

Tohle je pořadí. Každý krok má níže vlastní oddíl.

1. Zjisti, co čeká na aktualizaci. Vypiš aktualizace jádra, pluginů a šablon. U všeho, co přeskakuje hlavní verzi, si přečti seznam změn.
2. Zálohuj ostrý web: všechny soubory a zvlášť výpis databáze.
3. Obnov testovací kopii z té zálohy. Obnov soubory, naimportuj databázi, přepiš adresy a vypni věci, které kopie dělat nesmí.
4. Aktualizuj testovací kopii a otestuj ji podle písemného seznamu stránek a akcí.
5. Aktualizuj ostrý web ve stejném pořadí, v klidné hodině, se zálohou z kroku 2 po ruce.
6. Zkontroluj ostrý web a poznamenej si, co se změnilo a kdy.

Diagram ukazuje jednu podstatnou věc: testovací kopie se staví ze zálohy, ne přímo z ostrého webu. Je to záměr. Každé provedení postupu tak prověří cestu obnovy, a pokud obnova selže, dozvíš se to v úterý, kdy o nic nejde, a ne během výpadku.

Krok 1: zjisti, co čeká na aktualizaci#

Seznam si přečteš ve wp-admin pod Nástěnka, pak Aktualizace. Pokud máš tam, kde WordPress běží, shell, WP-CLI vypíše totéž ve tvaru, který můžeš vložit do poznámky:

$ wp core check-update$ wp plugin list --update=available --fields=name,version,update_version$ wp theme list --update=available --fields=name,version,update_version

Dvě pravidla pro čtení toho seznamu. Zaprvé: plugin, který přeskakuje hlavní verzi (třeba 4.x na 5.x), si přečti celý changelog, protože právě tam autoři oznamují odstraněné funkce a migrace databáze. Zadruhé: plugin, který autor dva roky neaktualizoval, chce rozhodnutí hned, ne až v den aktualizace: nahradit ho, nebo přijmout, že je to riziko. Článek zabezpečení WordPressu vysvětluje, proč jsou opuštěné pluginy obvyklou cestou, kterou se weby dostanou do rukou útočníků.

Zapiš si také používanou verzi PHP. Ve wp-admin ji najdeš v Nástroje, pak Stav webu, pak Info, pak Server. Testovací kopie musí běžet na stejné, jinak test nic neříká.

Krok 2: záloha souborů a databáze#

Záloha WordPressu jsou dvě věci a kopie jen jedné z nich zálohou není. Soubory obsahují wp-content (šablony, pluginy, nahrané soubory) a wp-config.php. Databáze obsahuje každý příspěvek, stránku, komentář, uživatele a nastavení. Obnova souborů bez databáze dá web se šablonou a bez obsahu; obnova databáze bez souborů dá obsah odkazující na chybějící obrázky.

Nejdřív udělej zálohu souborů, hned po ní výpis databáze. Na webových tarifech RE:NODE je záloha tlačítko nebo úloha na záložce Schedules a sloty pro zálohy jsou součástí každého tarifu; záloha pokrývá soubory serveru, takže výpis databáze je samostatný krok, který děláš sám. Pokud máš shell, nejkratší cesta je mysqldump přes WP-CLI:

$ wp db export - --single-transaction | gzip > ~/pre-update-$(date +%F).sql.gz$ gzip -t ~/pre-update-$(date +%F).sql.gz && echo "archive readable"

Bez WP-CLI stejnou práci udělá mysqldump s přístupovými údaji z wp-config.php:

$ mysqldump --single-transaction --no-tablespaces \    -h DB_HOST -u DB_USER -p DB_NAME | gzip > pre-update.sql.gz

Přepínač --single-transaction pořídí konzistentní snímek tabulek InnoDB bez zamykání webu. Přepínač --no-tablespaces odstraní chybu oprávnění na hostingu, kde uživatel databáze nemá oprávnění PROCESS, což je běžný případ uživatele, který smí sahat jen na svou databázi. Přepínače podrobně pokrývá článek záloha a obnova přes mysqldump.

Pokud je u tarifu v panelu stránka s databázemi, existuje druhá cesta bez shellu: Open in phpMyAdmin tě přihlásí jednorázovým tokenem a Export, pak Custom, pak gzip vytvoří stejný soubor. Limity velikosti, o které se větší databáze zasekávají, popisuje průvodce importem a exportem v phpMyAdminu.

Pak stáhni oba soubory ze stroje pryč. Záloha, která leží vedle toho, co chrání, je pohodlí, ne pojistka. Zálohy z panelu lze stáhnout; výpis také, přes SFTP nebo správce souborů (SFTP a správce souborů). Když zálohu v panelu zamkneš, přežije i rotaci, která při vytvoření nové smaže nejstarší slot. U zálohy před aktualizací to udělej a zámek sundej, až bude aktualizace týden v pořádku.

Krok 3: postav testovací kopii#

Testovací kopie je druhá instalace WordPressu, která drží čerstvou kopii ostrého webu. Může to být subdoména ve stejném účtu, druhý malý tarif nebo složka na stroji, který spravuješ sám. Požadavků je málo:

• Stejná verze PHP jako na ostrém webu a podobný limit paměti. Testovací kopie na PHP 8.4, která testuje ostrý web na 8.2, o aktualizaci nic neprokáže.
• Vlastní databáze. Testovací kopii nikdy nepřipojuj na ostrou databázi, ani „jen se podívat“. Plugin, který by na testovací kopii upravil tabulky, by pak změnil i ostrý web.
• Vlastní adresa, například staging.example.com, s HTTPS. Tarify aplikací a webu na RE:NODE obsahují slot proxy: nasměruj A záznam na zobrazenou adresu a certifikát se vydá a obnovuje automaticky. Nejčistší testovací kopie je druhý server s WordPressem a tarify WordPress začínají v době psaní na $5 měsíčně - aktuální nabídku najdeš na stránce webhostingu. Obecné důvody, proč mít dvě prostředí a v čem je záměrně udělat odlišná, rozebírá článek staging a produkce v jednom účtu.

Teď do ní obnov data. Kroky jsou stejné jako při stěhování, které podrobněji popisuje článek přesun WordPressu na nový hosting; tady je zkrácená verze.

1. Rozbal zálohu souborů do kořenového adresáře testovací kopie.
2. Uprav wp-config.php testovací kopie tak, aby DB_NAME, DB_USER, DB_PASSWORD a DB_HOST měly hodnoty testovací databáze. Nekopíruj ty z ostrého webu.
3. Naimportuj výpis.
4. Přepiš adresy.

$ gunzip -c pre-update-2026-10-20.sql.gz | wp db import -$ wp search-replace 'https://example.com' 'https://staging.example.com' \    --skip-columns=guid --all-tables --dry-run$ wp search-replace 'https://example.com' 'https://staging.example.com' \    --skip-columns=guid --all-tables

Vždy nejdřív spusť --dry-run a přečti si počet náhrad v jednotlivých tabulkách. wp search-replace rozumí serializovaným datům PHP, proto existuje: prosté SQL REPLACE() na serializované volbě změní délku řetězce, ale neaktualizuje délku uloženou vedle něj, a WordPress pak celou volbu považuje za poškozenou. --skip-columns=guid nechává GUID příspěvků na pokoji, protože jde o identifikátory, ne odkazy, a při přesunu webu se nemají měnit.

Pokud nemáš shell, stejnou práci z wp-admin udělá plugin Better Search Replace a pravidlo o serializovaných datech platí i pro něj. Nikdy nepoužívej hledání a nahrazování v textovém editoru na souboru s výpisem.

Ať se kopie chová jako kopie

Testovací kopie, která se chová jako originál, je nebezpečná. Posílá e-maily originálu, strhává peníze přes platební bránu originálu, publikuje na sociální sítě originálu a ve vyhledávání se objevuje jako duplikát tvého skutečného webu. Přidej tohle do wp-config.php testovací kopie nad řádek, který říká, že už nemáš nic upravovat:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );define( 'DISABLE_WP_CRON', true );define( 'WP_DEBUG', true );define( 'WP_DEBUG_LOG', true );define( 'WP_DEBUG_DISPLAY', false );define( 'AUTOMATIC_UPDATER_DISABLED', true );

Co která konstanta dělá:

Ladicí log patří jen na testovací kopii. Na ostrém webu je veřejně čitelný debug.log únik informací. Konstanta pro cron je vysvětlena v článku WP-Cron a skutečný cron; na testovací kopii chceš opak toho, co ten článek nastavuje na ostrém webu.

Potom zastav odchozí poštu a indexování vyhledávači. Nejdřív pošta, jako malý povinný plugin, který přežije změny pluginů. Vytvoř wp-content/mu-plugins/staging-no-mail.php:

<?php// Staging only: wp_mail() returns false and nothing is sent.add_filter( 'pre_wp_mail', '__return_false' );

Cokoli, co posílá poštu jinou cestou, například plugin s vlastním SMTP nebo integrací přes API, musíš vypnout v nastavení toho pluginu. Zvlášť zkontroluj platební brány: přepni je do testovacího režimu, nebo plugin na testovací kopii deaktivuj.

Pak vyhledávače:

$ wp option update blog_public 0

Tím se zapne „Požádat vyhledávače, aby web neindexovaly“, což přidá signál noindex. Je to žádost, ne zámek, takže adresu testovací kopie také nedávej do žádného veřejného odkazu. Pokud hosting nabízí ochranu subdomény heslem, použij ji; přihlašovací okno je jediný spolehlivý způsob, jak odradit roboty i zvědavé zákazníky.

Nakonec udělej vzhled kopie rozeznatelný, aby je nikdo nezaměnil. Stačí banner nebo jiné barevné schéma administrace. Aktualizovat špatnou záložku na konci dlouhého dne je přesně to, jak takový postup selže.

Krok 4: aktualizuj testovací kopii a otestuj ji#

Aktualizuj v pořadí, ze kterého je příčina selhání zřejmá: jednu věc po druhé a, pokud se to dá, testuj mezi nimi.

$ wp plugin update --all$ wp theme update --all$ wp core update$ wp core update-db

Pořadí je záměrné. wp core update-db spouští aktualizaci databáze, která následuje po hlavním vydání jádra, a jádro až na konci znamená, že selhání pluginu nesplete se selháním jádra. Pokud máš pluginů hodně, aktualizuj je po třech čtyřech a testuj mezi dávkami; když se něco rozbije, viník je v poslední dávce. Pokud se rozbije i s jedním pluginem z dávky, deaktivuj ho a ověř to:

$ wp plugin deactivate suspect-plugin$ wp plugin list --status=active --fields=name,version

Testuj podle seznamu, ne podle pocitu

„Proklikal jsem to a vypadalo to dobře“ otestuje jen to, na co sis vzpomněl kliknout. Měj v poznámce krátký písemný seznam a odškrtávej ho při každém běhu. Typický seznam pro malý firemní web:

Než rozhodneš, že test prošel, přečti si log. Web může vypadat dobře, zatímco plugin zapisuje fatální chybu při každém požadavku a cache ji skrývá. Závěrečnou kontrolu dělej s vyčištěnou cache, protože stránky z cache nic netestují:

$ wp cache flush$ tail -n 50 wp-content/debug.log

Spusť také kontrolu integrity, která porovná soubory jádra s oficiálními kontrolními součty:

$ wp core verify-checksums$ wp db check

Neshodující se kontrolní součet u souboru, který jsi neupravoval, znamená, že jádro někdo změnil. Je dobré to vědět dřív, než stejnou aktualizaci nasadíš na ostrý web.

Pokud test selže, dozvěděl ses, kvůli čemu jsi přišel. Poznamenej si, který plugin nebo šablona to způsobily, rozhodni se, jestli počkat na opravené vydání, plugin nahradit, nebo právě ten jeden zafixovat na současné verzi, a ostrou aktualizaci proveď bez něj. Ostrý web zůstal nedotčený.

Krok 5: aktualizuj ostrý web#

Teprve teď. Udělej čerstvou zálohu a výpis databáze, protože ta z kroku 2 je už hodiny nebo dny stará a mezitím přibyly příspěvky, objednávky a komentáře. Potom:

1. Zapni režim údržby, pokud web přijímá objednávky nebo odeslání formulářů. wp maintenance-mode activate to udělá přes WP-CLI; dvojice activate a deactivate je celé rozhraní.
2. Spusť přesně ty příkazy aktualizace, které jsi spustil na testovací kopii, ve stejném pořadí.
3. Vyčisti cache: plugin pro cache, objektovou cache, pokud ji máš, a případné CDN.
4. Projdi stejný seznam kontrol, tentokrát na ostré adrese.
5. Vypni režim údržby.

Dělej to v nejklidnější hodině podle své analytiky, ale ne před spaním. Aktualizace v jedenáct večer a zjištění v sedm ráno, že pokladna nejde, stojí celou noc objednávek; aktualizace ve dvě odpoledne v klidný všední den a zjištění ve 14:20 stojí pár minut. „Klidno“ je méně důležité než „jsem tu a můžu to vrátit“.

Vrácení, když to přesto dopadne špatně

Testovací kopie zachytí většinu problémů, ne všechny, protože nemá provoz, cache ani aktuální data ostrého webu. Pokud se ostrý web přesto rozbije, máš tři páky v pořadí rostoucí ceny:

1. Deaktivuj viníka. Pokud web ukazuje bílou obrazovku a do wp-admin se nedostaneš, přejmenuj složku pluginu v wp-content/plugins přes SFTP nebo ve správci souborů, nebo spusť wp plugin deactivate name. Obvykle to stačí.
2. Přeinstaluj předchozí verzi toho pluginu, pokud aktualizace nezměnila databázi. wp plugin install name --version=1.2.3 --force nainstaluje konkrétní vydání. Pokud plugin své tabulky zmigroval, starší verze jim nemusí rozumět.
3. Obnov zálohu z kroku 5, soubory i databázi, čímž přijdeš o vše, co se od té doby zapsalo. U e-shopu je to skutečná cena, a proto existuje krok s režimem údržby.

Smysl nácviku na testovací kopii je v tom, že vracení by skoro nikdy nemělo dojít až ke třetí páce.

Krok 6: dokaž, že obnova funguje#

Záloha, kterou nikdo neobnovil, je hypotéza. Všechno výše předpokládá, že import pre-update.sql.gz vyrobí funkční web. Zjistíš to jedině importem a obnova testovací kopie v kroku 3 je přesně tenhle test, pokud problém v ní bereš jako nález, ne jako obtěžování.

Udělej kontrolu výslovnou, ne jen implicitní. Po každé obnově porovnej testovací kopii s tím, co víš o ostrém webu:

$ wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_status='publish';"$ wp db query "SELECT COUNT(*) FROM wp_users;"$ wp post list --post_type=page --post_status=publish --format=count

Spusť stejný dotaz na ostrém webu: čísla by měla sedět s přesností na to, co se publikovalo mezi zálohou a kontrolou. Předpony tabulek se mezi weby liší; wp db prefix vypíše tu tvou. Pak otevři nejnovější příspěvek a nejnovější nahraný soubor, protože obnova se správnými počty a bez obrázků je pořád neúspěšná obnova.

Tři kontroly zachytí většinu špatných záloh:

• Archiv je čitelný: gzip -t file.sql.gz nevypíše nic, pokud je neporušený. Uříznuté stažení nebo plný disk se ukáží tady.
• Soubor má věrohodnou velikost. Pokud je výpis desetinový oproti minulému měsíci, něco potichu selhalo, a zálohovací úloha, která šest týdnů zapisuje soubory o 2 KB, je běžnější, než by měla být.
• Obnova skončí bez chyb. Výpis uříznutý uprostřed CREATE TABLE se „úspěšně“ naimportuje, pokud chyby pošleš do ztracena. Čti výstup.

Jednou za čtvrtletí jdi o krok dál a obnov do úplně prázdné databáze a prázdné složky jen ze souborů zálohy a svých poznámek. To je verze testu, která odpovídá skutečné katastrofě, kdy nemáš starou instalaci, ze které by sis půjčil nastavení. Úvahy podrobněji rozebírají články vyzkoušej obnovu, než ji budeš potřebovat a zálohy, které se opravdu obnoví.

Na RE:NODE je obnova zálohy z panelu jedno tlačítko na záložce Backups, takže souborová půlka kontroly je rychlá; půlka s databází je import, který děláš sám, a proto výpis patří do postupu, ne do paměti.

Automatizace nudných částí#

Postup přežije, jen když je levný. Tři věci stojí za to automatizovat.

Plánovaná záloha souborů. Záložka Schedules spouští zálohy podle výrazu cron, takže denní záloha v brzkých ranních hodinách nepotřebuje žádný vlastní skript. Přidej druhý plán s několikaminutovým zpožděním pro výpis, pokud ho můžeš spouštět ze stejného místa. Syntaxi popisuje článek výrazy cron vysvětleně.

Plánovaný výpis databáze, pokud máš shell:

0 3 * * * cd /var/www/example.com && /usr/local/bin/wp db export - --single-transaction | gzip > /var/backups/wp-$(date +\%F).sql.gz

Zpětné lomítko před % je v crontabu důležité; neescapované % se bere jako nový řádek. Staré výpisy odstraníš příkazem find /var/backups -name 'wp-*.sql.gz' -mtime +14 -delete.

Skript pro obnovu testovací kopie, který provede kroky z kroku 3 najednou, aby obnova byla příkaz, a ne dvacet minut klikání. Jeho tvar je: rozbalit soubory, naimportovat výpis, spustit search-replace, zapsat konstanty testovací kopie. Drž ho v poznámce nebo v soukromém repozitáři bez přístupových údajů; ty ber z prostředí. Když ho poprvé napíšeš, objevíš jeden ruční krok, na který jsi zapomněl, a to je nejlepší argument pro skript.

I o automatických aktualizacích na pozadí je třeba rozhodnout. WordPress ve výchozím stavu instaluje drobná vydání jádra. Automatické aktualizace pluginů a šablon lze zapínat po jednotlivých položkách ve wp-admin. Rozumná politika: drobná vydání jádra zapnutá a u pluginů automaticky aktualizovat ty, jejichž rozbití si můžeš dovolit, ostatní vést postupem výše. Takhle vypneš vše na webu, který aktualizuješ ručně:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );add_filter( 'auto_update_plugin', '__return_false' );

První řádek je zapsané výchozí chování; filtr (patří do malého povinného pluginu, ne do wp-config.php, který se načítá dřív, než lze filtry přidávat) vypne automatické aktualizace pluginů. Nevypínej bezpečnostní opravy všude a pak na web nezapomeň.

Chyby, kvůli kterým je testovací kopie zbytečná#

Testovací kopie selhává několika předvídatelnými způsoby a všechny končí zeleným testem a rozbitým ostrým webem.

• Rozešla se. Kopie vznikla v březnu a od té doby se neobnovila. Na ostrém webu je dvanáct nových pluginů a jiná šablona. Stavěj kopii znovu z čerstvé zálohy pokaždé - proto to postup dělá.
• Má jinou verzi PHP nebo limit paměti, takže aktualizace projde tam, kde by na ostrém webu neprošla.
• Nemá skutečná data. Testovací kopie se třemi zkušebními příspěvky nikdy neukáže plugin, který se dusí tabulkou o 40 000 řádcích. Obnov skutečnou databázi.
• Posílá skutečné e-maily nebo přijímá skutečné platby. Viz konstanty výše.
• Někdo ji upravuje přímo, a oprava, která „fungovala na testovací kopii“, je ručně upravený soubor, který se na ostrý web nikdy nedostane. Změny jdou stejnou cestou na obě strany.
• Je to ostrá databáze. Nejlevnější chyba s nejdražším výsledkem. Zkontroluj DB_NAME, než cokoli uděláš.

Nic z toho není exotické. Stává se to proto, že testovací kopie působí jako nepovinná, a nepovinná je jen do první aktualizace, která rozbije ostrý web.

FAQ#

Potřebuju testovací kopii pro malý blog?

Ne vždy. Blog s bezplatnou šablonou, čtyřmi pluginy a bez obchodu si může rozumně vystačit se zálohou, aktualizací na ostrém webu a kontrolou, protože nejhorší realistický výsledek je krátký výpadek, který se vrátí ze zálohy. Testovací kopie se vyplatí, jakmile web přijímá peníze, sbírá poptávky nebo používá page builder a vlastní kód.

Můžu místo druhé instalace použít staging plugin?

Takové pluginy umí web naklonovat do podsložky nebo subdomény a změny poslat zpět. Fungují, ale mají stejná úskalí jako ruční kopie (sdílené nahrávky, zatoulaná pošta, kolize předpon databáze) a krok zpět může přepsat obsah vytvořený na ostrém webu od okamžiku kopírování. Samostatná instalace postavená ze zálohy se lépe chápe a zároveň testuje tvou obnovu.

Jak často aktualizovat?

Kontroluj týdně a bezpečnostní vydání nasazuj do dne nebo dvou. Ostatní projdi plným postupem v pevný čas, například první pracovní den v měsíci. Když se aktualizace hromadí, každá dávka je větší a viníka je těžší najít.

Má testovací kopie používat stejný databázový server jako ostrý web?

Použij samostatnou databázi na stejném enginu a stejné hlavní verzi. Stejný server je přijatelný, pokud ti tarif dává víc než jednu databázi; záleží na izolaci, tedy na oddělených přístupových údajích a oddělném schématu, aby chyba na testovací kopii nemohla zasáhnout ostrá data.

Co dělat, když aktualizace web rozbije a nedostanu se do wp-admin?

Přejmenuj složku wp-content/plugins/name právě aktualizovaného pluginu, nebo celou složku plugins, přes SFTP nebo ve správci souborů. WordPress deaktivuje, co nenajde, a administrace se obvykle otevře. Přečti si wp-content/debug.log, abys potvrdil, který plugin to byl, než cokoli vrátíš.

Je obnova ze zálohy totéž co návrat o krok zpět?

Ne. Návrat po neúspěšné aktualizaci by měl vrátit jen plugin nebo šablonu, které selhaly. Obnova vrátí celý web do okamžiku zálohy a vše zapsané od té doby je pryč. Ber obnovu jako poslední možnost a postup výše jako důvod, proč ji potřebuješ jen zřídka.