WordPress zaseknutý v režimu údržby: oprava aktualizací

Pokud web hlásí "Briefly unavailable for scheduled maintenance. Check back in a minute." a hlásí to déle než deset minut, aktualizace byla přerušena a v kořeni WordPressu po sobě nechala soubor .maintenance. Smaž ho ve správci souborů nebo přes SFTP a web se vrátí. Tím vyléčíš příznak. Příčina je obvykle jedna ze čtyř: uprostřed aktualizace došel časový nebo paměťový limit PHP, WordPress nesměl zapisovat do nějakého adresáře, zaplnil se disk, nebo byla v nevhodnou chvíli zavřená karta prohlížeče. Dokud nevíš, která z nich to je, další aktualizace skončí stejně.

Tento článek pokrývá celou rodinu problémů: zaseknutou stránku údržby, "Another update is currently in progress", "Could not copy file", žádost o přihlašovací údaje k FTP, aktualizaci pluginu, po které web spadl, a ruční aktualizaci, když administrace nepomůže. Všechno jde udělat správcem souborů nebo přes SFTP a každá část říká, co zkontrolovat dřív, než cokoli změníš.

Co WordPress při aktualizaci dělá#

Aktualizace není jedna operace a znalost pořadí kroků napoví, kde přesně se selhání stalo. Když aktualizuješ jádro, plugin nebo šablonu z administrace, WordPress zhruba:

1. Stáhne zip do dočasného umístění a zkontroluje ho.
2. Zapíše do kořene webu soubor .maintenance. Od této chvíle návštěvníci vidí stránku údržby.
3. Rozbalí archiv do wp-content/upgrade/.
4. Zkopíruje nové soubory přes staré, adresář po adresáři.
5. Smaže rozbalené soubory a soubor .maintenance.
6. Po aktualizaci jádra spustí aktualizaci databáze při dalším vstupu správce do administrace.

Kroky 2 až 5 jsou nebezpečné okno a na zdravém hostingu trvá několik sekund. Cokoli, co v něm zabije PHP, nechá web v polovičním stavu: soubor údržby zůstane, část souborů je nová a část stará, nebo zůstane zbytek v wp-content/upgrade/. WordPress je postavený tak, aby se z většiny takových případů zotavil, proto stránka údržby sama vyprší, ale z požadavku, který nedostal šanci doběhnout, se zotavit neumí.

Soubor .maintenance je drobný. Obsahuje časové razítko:

<?php $upgrading = 1761000000; ?>

WordPress porovná to číslo s aktuálním časem. Je-li soubor mladší než deset minut, zobrazí stránku údržby. Po deseti minutách ho ignoruje a web obsluhuje normálně. Pokud tedy vidíš stránku čtvrt hodiny po začátku aktualizace, buď se souboru stále dotýká běžící aktualizace (vzácné), nebo stránku podává cache. Obojí je rozebráno níže.

Jak opravit web zaseknutý v režimu údržby#

Soubor se jmenuje .maintenance, s tečkou na začátku, a proto ho lidé nemohou najít. Soubory začínající tečkou jsou v mnoha klientech SFTP a některých výpisech souborů skryté.

1. Otevři správce souborů nebo klienta SFTP a přejdi do složky, kde leží wp-config.php. To je kořen WordPressu.
2. Zapni zobrazení skrytých souborů. Ve FileZille je to Server, Force showing hidden files. Ve WinSCP Options, Preferences, Panels, Show hidden files.
3. Smaž .maintenance.
4. Načti web v anonymním okně, aby tě nesvedla uložená kopie stránky údržby.

Pokud se web vrátil, tady nekonči. Otevři Dashboard, Updates. Pokud WordPress nabízí stejnou aktualizaci znovu, předchozí pokus nedoběhl a nejspíš je jádro nebo plugin zkopírovaný jen zčásti. Než ji spustíš podruhé přes tu první, přečti si část o opravě nedokončené aktualizace.

Pokud je soubor pryč a zpráva o údržbě stále je, stránka přichází z cache. Obvyklými zdroji jsou cachovací plugin, který stránku uložil, zatímco .maintenance existoval, cache stránek na straně serveru a CDN. Vymaž cache pluginu na jeho stránce nastavení, a pokud administrace nejde, smaž obsah wp-content/cache/. Pokud před webem stojí CDN nebo proxy, vyčisti i tu - Cloudflare pro weby a herní servery vysvětluje, které jeho vrstvy cachují HTML a které ne.

Druhou, méně častou příčinou je vlastní stránka údržby. WordPress zobrazí wp-content/maintenance.php místo výchozí zprávy, pokud tento soubor existuje. Pluginy s režimem údržby nebo stránkou "brzy otevíráme" často fungují právě tak, že ho vytvoří. Pokud na obrazovce není standardní věta, hledej tento soubor nebo stále zapnutý plugin údržby.

"Another update is currently in progress"#

Aktualizátor jádra si bere zámek, aby ho nemohly spustit dvě karty prohlížeče nebo dva správci naráz. Zámek je řádek v databázi, v tabulce wp_options, s názvem core_updater.lock. Uvolní se, když aktualizace skončí. Pokud PHP uprostřed aktualizace zemře, řádek zůstane a dalších 15 minut odmítá WordPress spustit další aktualizaci jádra hláškou "Another update is currently in progress".

Poctivá oprava je počkat patnáct minut a zkusit to znovu. Zámek má platnost a po jejím uplynutí WordPress starý řádek ignoruje. Pokud čekat nemůžeš, nebo si chceš ověřit, že problém je v tom řádku, smaž ho. Na RE:NODE tlačítko "Open in phpMyAdmin" v panelu přihlásí jednorázovým tokenem, který vyprší za 60 sekund, takže žádné heslo nepíšeš. Spusť to v záložce SQL a uprav předponu tabulek, pokud není wp_:

SELECT option_id, option_name, option_valueFROM wp_optionsWHERE option_name = 'core_updater.lock';DELETE FROM wp_optionsWHERE option_name = 'core_updater.lock';

Nejdřív ověř, že žádná aktualizace opravdu neběží. Smazání zámku uprostřed kopírování zve přesně to poškození, které má zámek předcházet. Pokud soubor .maintenance existuje a byl zapsán před minutou nebo dvěma, může ještě něco pracovat. Počkej a zkontroluj znovu.

Stejná zpráva se objevuje i z jiného důvodu, na webech s rozbitou plánovanou úlohou. WordPress spouští aktualizace na pozadí z vlastního plánovače, takže na webu s rozbitým cronem může zámek držet proces, který nikdy neskončí. WP-Cron versus skutečný cron vysvětluje, jak to poznat a jak plánovač zpolehlivit.

Proč aktualizace selhávají: příčiny podle pravděpodobnosti#

Většina selhání pochází z krátkého seznamu. Kontroluj je v tomto pořadí, protože ty první se vyloučí rychle a ty poslední jsou drahé.

Místo na disku. Aktualizace potřebuje místo najednou na zip, rozbalenou kopii i nové soubory, takže aktualizace jádra může krátce potřebovat třikrát tolik, co zabírá to, co nahrazuje. Na malém tarifu s velkou složkou nahraných souborů to na selhání stačí. Podívej se na graf disku v konzoli panelu, který ukazuje disk proti limitu, a uvolni, co nepotřebuješ: staré zipy pluginů, obsah wp-content/upgrade/, složky cache a archivy záložních pluginů ponechané uvnitř wp-content. Záložní plugin, který píše archivy vedle webu, je nejčastější způsob, jak se malý disk WordPressu zaplní.

Limity. Aktualizace jádra rozbaluje a kopíruje tisíce malých souborů, což na rychlém úložišti trvá pár sekund a na vytíženém stroji podstatně déle. Pokud je max_execution_time nastavený velmi nízko, nebo je memory_limit tak malý, že na něj narazíš při rozbalování, PHP proces uprostřed kopírování zastaví. Hodnoty ke kontrole a jak je zvýšit najdeš v článku nastavení PHP, na kterých pro WordPress záleží. Orientačně: 256M pro memory_limit a alespoň 60 sekund pro max_execution_time je rozumné minimum pro aktualizace. Kolik RAM potřebuje WordPress pokrývá druhou stranu: limit, který PHP dovolí, ale tarif nedokáže poskytnout.

Odchozí spojení. Server stahuje aktualizaci z wordpress.org, takže potřebuje odchozí HTTPS. Pokud selže DNS nebo požadavek zablokuje firewall, uvidíš chybu stahování dřív, než se jakýkoli soubor dotkne. To je nejbezpečnější selhání, protože se nic nezměnilo. Zkus to později, a pokud to přetrvává, otevři Tools, Site Health a přečti si kontroly "WordPress.org REST API" a loopback.

Oprávnění souborů a žádost o údaje k FTP#

Tohle selhání lidi mate nejvíc. Klikneš na Update a WordPress ukáže formulář s žádostí o údaje k FTP nebo SFTP, nebo skončí chybou "Could not create directory". Ani jedno neznamená, že máš špatné heslo. Znamená to, že WordPress zkusil, jestli smí zapisovat do vlastních složek, a došel k závěru, že ne.

WordPress si vybírá způsob zápisu souborů. Ve výchozím stavu vytvoří v wp-content malý dočasný soubor a porovná jeho vlastníka s vlastníkem souborů, které tam už jsou. Pokud se shodují, zapisuje přímo. Pokud se liší, předpokládá, že PHP web nevlastní, a vrátí se k žádosti o údaje k FTP. Ten dotaz je tedy ve skutečnosti příznakem smíšených vlastníků: část souborů vytvořil jeden uživatel, typicky ten, kdo je nahrál přes SFTP nebo obnovil z archivu, a PHP běží pod jiným.

Typická oprávnění, tam kde je hosting dovolí nastavit:

Do adresáře se vstupuje díky bitu spuštění, proto 644 na složce rozbije všechno pod ní. Nikdy nepoužívej 777. Neřeší problém vlastníka, jen udělá každý soubor zapisovatelný pro každý účet na stroji, a to je první, co útočník hledá. Zbytek příběhu o oprávněních najdeš v článku zabezpečení WordPressu.

Tam, kde můžeš spouštět příkazy, jsou na opravu dva řádky, spuštěné z kořene WordPressu:

$ find . -type d -exec chmod 755 {} +$ find . -type f -exec chmod 644 {} +

Na hostingu s panelem často vlastníka vůbec změnit nemůžeš a málokdy to potřebuješ. Správce souborů a SFTP pracují se stejnými soubory, které servíruje PHP, takže soubory, které jimi vytvoříš, bývají pro web zapisovatelné. Problém se obvykle objeví po obnově, po rozbalení archivu jiným nástrojem nebo po migraci, která přenesla starého vlastníka. Pak je správná cesta tiket, protože oprava je na straně hostingu. SFTP: permission denied při úpravě souborů ukazuje, jak odlišit problém režimu od problému vlastníka.

Pokud víš, že soubory webu jsou zapisovatelné a WordPress se přesto ptá, můžeš mu to hádání zakázat přidáním řádku do wp-config.php, nad komentář "That's all, stop editing":

define( 'FS_METHOD', 'direct' );

To žádné oprávnění nepřidělí. Jen zastaví WordPress v jeho vlastním odhadu. Pokud soubory opravdu zapisovatelné nejsou, aktualizace teď selže prostou chybou oprávnění místo formuláře, což je užitečnější. Po opravě skutečné příčiny řádek zase odstraň.

Oprava nedokončené aktualizace#

Když aktualizace zemřela v půlce, mohou zůstat tři druhy zbytků. Řeš je v tomto pořadí a nejdřív udělej zálohu.

1. Zálohuj, co tam je. Rozbitý web je pořád lepší než smazaný. Udělej v panelu zálohu serveru, a pokud se dostaneš k databázi, exportuj i tu. Otestuj obnovu dřív, než ji budeš potřebovat stojí za přečtení, dokud nespěcháš.

2. Vyčisti dočasné složky. WordPress rozbaluje aktualizace do wp-content/upgrade/. Na zdravém webu je tato složka prázdná. Cokoli uvnitř jsou trosky neúspěšného běhu a zbylá složka je příčinou "Destination folder already exists". Smaž obsah, ne samotnou složku. Od WordPressu 6.3 uchovávají aktualizace pluginů a šablon starou verzi také v wp-content/upgrade-temp-backup/, aby se neúspěšná aktualizace dala vrátit. Pokud tam leží adresář pluginu, který jsi aktualizoval, a jeho pracovní adresář je rozbitý nebo chybí, je ta kopie nejrychlejší cesta zpět k funkční verzi: přesuň ji do wp-content/plugins/.

3. Přeinstaluj to, co se aktualizovalo. Pokud přerušená aktualizace byla plugin nebo šablona, smaž jeho složku a nahraj čerstvou kopii. To je bezpečné, protože nastavení žije v databázi, ne v souborech pluginu. Pokud šlo o jádro, udělej ruční aktualizaci jádra, což je další část. Potom aktualizaci spusť znovu z Dashboard, Updates.

Pokud web teď ukazuje kritickou chybu, aktualizace doběhla, ale nový kód nefunguje s něčím na tvém webu. To je jiný problém s jiným logem. Přejdi na bílá obrazovka a chyby 500 ve WordPressu, zapni WP_DEBUG_LOG a přečti poslední řádek debug.log. Plugin, který po aktualizaci selhává, jde vypnout přejmenováním jeho složky v wp-content/plugins/ a web se hned vrátí; jeho nastavení zůstává v databázi.

Ruční aktualizace WordPressu#

Ruční aktualizace je běžný nástroj, ne poslední záchrana. Funguje, když administrace nemůže, a je stejně bezpečná jako automatická cesta, pokud dodržíš pořadí. Je to stejná metoda, jakou popisuje dokumentace WordPressu.

1. Zálohuj soubory i databázi.
2. Stáhni nejnovější zip z wordpress.org a rozbal ho v počítači, nebo zip nahraj a rozbal na místě ve správci souborů, který archivy extrahuje tam, kde leží.
3. Pokud je administrace nedostupná, nic předem nevypínej. Pokud dostupná je, můžeš nejdřív vypnout cachovací pluginy.
4. Na serveru smaž složky wp-admin a wp-includes. Obsahují jen soubory jádra, tvůj obsah v nich není.
5. Nahraj nové wp-admin a wp-includes.
6. Nahraj samostatné soubory z kořene nového balíčku přes staré: index.php, wp-login.php, wp-settings.php a další. Nepřepisuj wp-config.php a nenahrazuj wp-content.
7. Uvnitř wp-content můžeš aktualizovat výchozí šablony a přibalené pluginy. Nikdy nemaž vlastní složky plugins, themes ani uploads.
8. V prohlížeči otevři /wp-admin/upgrade.php. Pokud je potřeba aktualizovat databázi, WordPress to provede a řekne ti to.
9. Smaž .maintenance, pokud tam ještě je, vyčisti cache a otestuj úvodní stránku, přihlášení a jeden příspěvek.

Důvod, proč se wp-admin a wp-includes mažou místo přepsání, je ten, že nová verze soubory nejen přidává, ale i odstraňuje. Přepsání nechá odstraněné soubory na místě a staré soubory se mohou omylem načíst. Smazat tyto dvě složky je bezpečné, protože nic tvého v nich není.

Pokud máš shell s WP-CLI, stejná práce je kratší a funguje i s nefunkční administrací:

$ wp core version$ wp core download --force --skip-content$ wp core update-db$ wp core verify-checksums

--skip-content nechává wp-content na pokoji. verify-checksums porovná soubory jádra s oficiálními a vypíše všechno změněné nebo chybějící, což je rychlý způsob, jak potvrdit, že nedokončená aktualizace je teď celá. Soubory pluginů hlásí zvlášť příkaz wp plugin verify-checksums --all. WP-CLI není součástí každého tarifu, takže základem ber cestu přes správce souborů a co k tomu nabízí panel RE:NODE, najdeš v poslední části tohoto článku.

Aktualizace pluginů a šablon, které rozbijí web#

Aktualizace jádra selhávají méně často než aktualizace pluginů, protože autoři pluginů testují na méně konfiguracích. Tři zvyky odstraní většinu bolesti.

Nejdřív aktualizuj kopii. Testovací web je jediný způsob, jak zjistit, že aktualizace rozbije pokladnu, dřív než to zjistí tví zákazníci. Postup s testovacím webem pro WordPress ukazuje, jak ho postavit, přenést změny a nepřepsat živé objednávky a komentáře.

Aktualizuj po jednom. Aktualizace patnácti pluginů jedním kliknutím znamená, že selhání má patnáct podezřelých. Aktualizuj, načti úvodní stránku a důležité stránky a pak pokračuj. U webu, který vydělává, to dělej v klidné hodině a s čerstvou zálohou udělanou těsně předtím.

Předem znej cestu zpět. Plugin, který web rozbije, jde vypnout přejmenováním jeho adresáře. Aby web běžel, přejmenuj wp-content/plugins/name na name.off a načti stránku znovu. Pokud nevíš, který plugin to je, přejmenuj celou složku plugins na plugins.off, čímž se vypnou všechny najednou. WordPress si toho všimne, vypne je v databázi a znovu ukáže administraci. Vrať složce původní jméno a zapínej pluginy po jednom, abys našel viníka. Chceš-li se vrátit k předchozí verzi pluginu, stáhni ji ze stránky pluginu na wordpress.org v části Advanced View, Previous Versions.

Automatické aktualizace mění sázky. WordPress si sám instaluje menší vydání jádra, většinou bezpečnostní opravy. Řídit to můžeš v wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Hodnoty jsou true (všechna vydání), false (žádná) a 'minor'. Menší aktualizace nech zapnuté. Automatické aktualizace pluginů se zapínají pro každý plugin zvlášť na obrazovce Plugins a nejlépe je vyhradit pluginům, o které bys mohl přijít na den, aniž by si toho kdo všiml. Cokoli, co obsluhuje platby, formuláře nebo rozložení šablony, by měl aktualizovat člověk, který se pak na web podívá.

Jak předejít další neúspěšné aktualizaci#

Společné vlákno neúspěšných aktualizací je, že nikdo nezařídil, aby bylo selhání levné. To zařídí krátká rutina.

• Měj rezervu. Na disku volné alespoň dvojnásobek velikosti jádra a tvého největšího pluginu a memory_limit 256M nebo víc.
• Měj zálohu, kterou jsi obnovoval. Ne jen udělal. Záloha, kterou jsi nikdy neobnovoval, je hypotéza. Zálohy, které se opravdu obnoví vysvětlují, jak ji otestovat bez rizika pro živý web.
• Aktualizuj, když je klid, a sleduj prvních pár minut. Většinu nedokončených aktualizací hned zaznamená ten, kdo je spustil.
• Plánuj zálohu před aktualizací. Plánovaná záloha hodinu před obvyklým oknem aktualizací znamená, že bod obnovy existuje, i když zapomeneš. Vzor ukazuje článek plánované úlohy, které stojí za to mít.
• Nezavírej kartu. Aktualizace běží uvnitř tvého požadavku. Zavření prohlížeče při rozbalování PHP vždy nezastaví, ale je to klasický způsob, jak skončit se zaseknutým souborem .maintenance.
• Udržuj čistý souborový řád. Zálohy, exporty a staré zipy do wp-content nepatří. Plní disk a jsou vydávány celému světu, pokud je cesta k nim snadno uhodnutelná.

Co pro to nabízí panel RE:NODE#

Většina toho, co je výše, nezávisí na hostingu, ale několik částí panelu odpovídá krokům přímo.

Řada WordPress na RE:NODE nainstaluje WordPress při prvním startu a wp-config.php už je zapsaný pro vlastní databázi MySQL, takže přístupové údaje k databázi jsou od začátku správné. Správce souborů má editor v prohlížeči, přijímá přetažené soubory i nahrání složek a rozbaluje archivy na místě, takže ruční aktualizace spočívá v nahrání jednoho zipu a jeho rozbalení. SFTP je na každém serveru, s přihlašovacími údaji pro každý server zvlášť. Grafy v konzoli ukazují paměť, CPU a disk proti limitům tarifu, takže nedostatek místa pro aktualizaci je vidět dřív, než začneš. Slot databáze se otevře v phpMyAdminu z panelu, a právě tak odstraníš řádek core_updater.lock.

Zálohy jsou na každém tarifu, lze je dělat na požádání nebo podle plánu, ukládají se mimo stroj, který chrání, a obnovují se tlačítkem, takže první krok každé opravy výše je jedno kliknutí. Plány mohou spustit zálohu před tvým oknem aktualizací. Pokud oprava potřebuje ruce hostingu - obnovu z kopie platformy nebo vlastnictví souborů, které změnit nemůžeš - otevři tiket z panelu, který se dostane ke všem zaměstnancům.

FAQ#

Jak dlouho má WordPress zůstat v režimu údržby?

Pár sekund u pluginu, až minutu u aktualizace jádra. Cokoli přes deset minut znamená, že aktualizace se zastavila. Samotný WordPress ignoruje soubor .maintenance starší deseti minut, takže stránka viditelná i potom je obvykle z cache nebo pochází z pluginu údržby.

Je bezpečné smazat soubor .maintenance?

Ano. Obsahuje jen časové razítko a WordPress ho při každé aktualizaci vytvoří znovu. Riziko není ve smazání, ale v předpokladu, že aktualizace doběhla. Po smazání zkontroluj Dashboard, Updates, a pokud se stejná aktualizace nabízí znovu, oprav ji, než to zkusíš znovu.

Přijdu o obsah, když aktualizace selže?

Příspěvky, stránky, komentáře a nastavení žijí v databázi, které se přerušené kopírování souborů nedotkne. Soubory pluginů, šablon a jádra mohou zůstat zapsané jen zčásti. Nahrané soubory aktualizace nemění. Zálohu před jakoukoli opravou přesto udělej.

Proč se WordPress ptá na údaje k FTP, když kliknu na aktualizovat?

Protože zjistil, že vlastník souborů, do kterých by zapisoval, není uživatel, pod kterým běží PHP, a předpokládá, že potřebuje údaje zvenčí. Příčina je ve vlastníkovi nebo režimu, ne v heslu. Oprav oprávnění, nebo o to požádej hosting, a údaje do formuláře nepiš.

Můžu aktualizovat pluginy na testovací kopii a pak výsledek přenést?

Ano, a je to nejbezpečnější cesta. Aktualizuj na testovacím webu, otestuj, pak stejné aktualizace zopakuj na ostrém webu, nebo přenes změněné soubory. Nekopíruj databázi z testovacího webu přes živý obchod, přišel bys o objednávky vytvořené od klonování.

Aktualizace proběhla, ale web ukazuje kritickou chybu. Co teď?

Nový kód je v konfliktu s tvou šablonou, jiným pluginem nebo verzí PHP. Přejmenuj složku pluginu, aby se vypnul, obnov web a přečti wp-content/debug.log, abys viděl, který soubor selhal a proč. Pak v seznamu změn pluginu zkontroluj nový požadavek na PHP.