Nebudeme si hrát na doktory, jde o název položky v nabídce WordPressu. Zobrazuje informace o tom, jak se vašemu webu daří nebo nedaří. Najdete zde i informace o nevhodném nastavení serveru nebo hostingu, což je asi nejpřínosnější.

Obsah

Souhrn konfigurace webu
Závažné problémy
Doporučená vylepšení
Úspěšné testy a správné nastavení

V záhlaví stránky se objevuje „semafor“, který barvou napovídá, jak váš WordPress splňuje technické a procesní požadavky. Připomínám, že jde primárně o aplikaci WordPress, nikoliv o výsledný web. Samozřejmě se mnoho z nalezených problémů týká i výsledného webu, ale nyní se na situaci dívejte optikou správce aplikace WordPress

Stránka má dvě karty – Stav a Informace. Na té první najdete v podstatě chybová hlášení a doporučení, těm se budeme věnovat dále. Stručně proto ke kartě Informace. Najdete tam souhrn a statistiku, přehled nastavení platformy, na které váš web běží.

Souhrn konfigurace webu

Jednotlivé sekce jsou rozklikávací, zkuste to na na sekci Adresáře a velikosti. Uvidíte tam velikost webu podle jednotlivých součástí – celý WP, adresář uploads, adresář šablon, pluginů, pak velikost databáze a vše dohromady. Pokud tato čísla vidíte, můžete stisknout tlačítko Zkopírovat informace o webu a uložit si textový soubor nebo text poslat mailem.

Pokud místo čísel vidíte nějakou probíhající animaci nebo slovo Načítání…, pak se součty teprve počítají – počkejte až doběhnou.

Tyto informace můžete poskytnout správci webu, pokud mu nechcete nebo nemůžete poskytnout plnohodnotný přístup do webu. Tyto informace shrnují o webu vše důležité, včetně konfigurace pluginů.

Pro shrnutí ještě typické sekce v běžném WordPressu:

WordPress
Adresáře a velikosti
Aktivní šablona
Neaktivní šablony (počet)
Aktivní pluginy (počet)
Neaktivní pluginy (počet)
Zpracování médií
Server
Databáze
Konstanty WordPressu
Oprávnění souborového systému

V každé najdete použité verze a klíčové hodnoty nastavení, které člověk potřebuje ověřit, když řeší nějaký problém. Třeba málo připojení do databáze nebo maximum paměti pro zpracování stránky.

Pojďme ale k jádru věci, na první kartu Stav, kde jsou problémy a doporučení. Různé pluginy přidávají do těchto sekcí vlastní testy, takže tam můžete najít další hlášky. Tyhle berte jako příklad.

Každý problém nebo příležitost má svou oblast, které se týká. Zobrazeny jsou jako štítky a jde o Bezpečnost, Výkon nebo třeba SEO.

Závažné problémy

Podle autorského týmu WordPressu jsou tyto problémy natolik vážné, že vám ani brufen nepomůže. Měli byste je opravit nebo začít otravovat někoho, kdo to má na starosti, aby je odstranil.

Byla detekována aktivní relace PHP

Relace, resp. říká se tomu i sezení (sešna), je způsob, jak server uloží data o vašich požadavcích, abyste mohli přecházet mezi více url stejného serveru, typicky když nastavujete aplikaci jako třeba WordPress. Pokaždé máte otevřenou pouze jednu relaci, to se v kódu zařídí příkazem session_start(), data mezi vašimi požadavky se ukládají právě do relace/session. Ta hláška nás informuje, že sezení dosud nebylo uzavřeno, což může znamenat, že jsou k dispozici pouze omezené zdroje (třeba časový limit), protože každá session má požadavky na výkon, prostor na disku a další zdroje.

Oprava není jednoduchá.

Někdy se stane, že webový server přestane sezení uzavírat a mazat (ukládají se často na disku serveru). Třeba došlo místo na daném disku.

Může dojít i k tomu, že autor pluginu, jehož novou verzi jste si právě nainstalovali, zapomněl v kódu uvést příkaz pro uzavření sezení. Zní to divně, ale taky jsem se s tím setkal. Obvykle pomůže hlášení chyby a oprava autorem.

V REST API došlo k chybě nebo REST API narazilo na neočekávaný výsledek

cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received

Častá chyba bývá s cURL, což je program (zkratka z client url), který přenáší data mezi servery, typicky tedy posílá žádost o data na nějaký API bod na serveru a očekává odtud odpověď. Jde o hlavní nástroj používaný pro komunikaci přes API.

O chybě 28 přímo dokumentace nic navíc neříká, takže si to můžeme nechat přežvýkat článkem třeba na Kinsta nebo jiném hostingovém blogu, kde vám mmj. poradí, abyste deaktivovali pluginy a nakonec kontaktovali svého poskytovatele hostingu. To vám samozřejmě skvěle pomůže… zkusme přemýšlet sami. Proč se program nemůže někam spojit, když to tak má standardně být?

Něco mu brání – a to buď při doručení dotazu, nebo při doručení odpovědi. Co se tedy může dít?

Cílový server není fyzicky dostupný, tzn. buď je offline nebo k němu nevede cesta přes DNS. To se stává, když má výpadek infrastruktura nebo je server třeba cílem DDoS útoku.
Cílový server je přetížený mnoha požadavky a nestíhá odpovídat.
Server je dostupný, ale dostali jste 🍌 , tedy (třeba dočasný) zákaz. Poslali jste víc požadavků za časový interval, než jste měli povoleno/zaplaceno nebo je vaše IP z nějakého důvodu na blacklistu nebo ji zablokoval firewall.

Ten vztah tam není přímočarý, takže bych doporučil v první řadě počkat hodiny nebo jednotky dnů. Ze zkušenosti vím, že se příčina chyby vyřeší tím, že bude dostatek zdrojů, tedy že nedostupnost byla dočasná.

Při testování REST API byl vrácen neočekávaný výsledek:

REST API Koncový bod: https://adresawebu.cz/wp-json/wp/v2/types/post?context=edit
REST API odezva: (502) Bad Gateway

Chyba ze série 50x se týká nastavení webového serveru. Na vyladěném hostingu se to nestává, ale člověk nechodí pořád v polobotkách, někdy je třeba obout gumáky, že. Takže v tomto případě nemá proces dostatek zdrojů ze strany webového serveru, třeba počet vláken, paměti, přístup k cílové url nebo dostatečně velkou hlavičku pro přenos všech argumentů v url.

Pokud máte aktivní třeba Wordfence, musíte ho naučit, že pracujete s REST API (což je např. práce v Gutenbergu). Jinak vám některé běžné operace může blokovat. Třeba vložíte v Gutenbergu jako snippet kousek JavaScriptu a šup, už jste za dveřmi. Takže nejprve v nastavení firewallu nastavte režim učení.

Web je nastaven na protokolování chyb do potenciálně veřejného souboru.

Tak to je snadné, vytváříte veřejně dostupný wp-content/debug.log, stačí ve wp-config.php nastavit na false tyto konstanty (používám všechny pro plnohodnotné ladění):

define('WP_DEBUG', false);
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SCRIPT_DEBUG', false );
define( 'SAVEQUERIES', false );

A soubor debug.log smažte, ofc.

Web nemohl dokončit požadavek zpětné smyčky

V linuxových systémech (a nejen tam, ale odtud to znám) existuje zařízení loopback s adresou 127.0.0.1, což je rezervovaná adresa v lokální síti, která směřuje na samotný stroj, který požadavek posílá. Čili může oslovit sám sebe „jakoby“ přes lokální síť, ve skutečnosti požadavek do sítě neputuje. Mmj. slouží také ke kontrole, že běžné požadavky, které mají procházet přes síť, budou fungovat. Jinými slovy – pokud nefunguje loopback, nebude fungovat komunikace ven. V případě WordPressu se loopback používá pro spouštění plánovaných úloh – crontasků. Běžně se tyto úlohy spouštějí v okamžiku, kdy na web přijde návštěvník (resp. požadavek, tj. stačí robot). Vytvoří se loopback požadavek k spuštění WP-Cronu, což umožňuje dané úloze běžet na pozadí, aniž by docházelo k dopadu na načítání stránky pro návštěvníka (=asynchronní běh). A proč tedy dochází k té chybě? Požadavek na loopback zařízení se nevytvoří, protože to zařízení není dostupné – a opět jsou to podobné příčiny jako výše u cURL, protože posíláme http (síťový) požadavek:

Server nebo databáze jsou přetížené, webový server (=na adrese 127.0.0.1) nemá zdroje.
V cronu běží předchozí požadavek – je v něm chyba a třeba se zacyklil nebo má ze strany serveru příliš dlouhélimity (timeout, což vede k prvnímu bodu).
Nefunguje správně cURL, viz výše.
Serverový firewall tyto požadavky blokuje, protože je mohl vyhodnotit jako DDoS.

Asi bude více příčin a mohou se řetězit, už je to přece jen složitější záležitost týkající se serveru. Cesta ven vede přes odstavení WP-Cronu a používání serverového cronu, který se spouští bez ohledu na to, jestli na web někdo přijde. A nezatěžuje loopback zařízení. A samozřejmě mít v cajku cURL, to je hlavní vehikl.

Jako adresu databázového serveru ve wp-config.php uveďte 127.0.0.1, pokud databáze běží na stejném serveru. Ušetříte si poměrně dost požadavků na DNS server, než když uvedete FQDN.

Mezipaměť stránek nebyla zjištěna a doba odezvy serveru je pomalá

Mezipaměť stránek je detekována vyhledáním aktivního pluginu mezipaměti stránek a provedením tří požadavků na domovskou stránku a hledáním jednoho nebo více z následujících hlaviček odpovědí mezipaměti klienta HTTP:

cache-control,expires,age,last-modified,etag,x-cache-enabled,x-cache-disabled,x-srcache-store-status,x-srcache-fetch-status.

Tato chyba se objevila v srpnu a září 2023 a to i tam, kde cachovací pluginy (a hlavičky) byly funkční, takže ji považuji za falešné hlášení. Ale stát se to může, jde opět o konfiguraci webového serveru, kde se do hlaviček vkládají některé z uvedených hodnot, aby bylo možné přenášená data cachovat.

Doporučená vylepšení

Tohle je pár obecných doporučení, občas se mezi nimi najde skutečně přínosná instrukce.

Měli byste smazat neaktivní pluginy/neaktivní šablony

Někdy chceme některý plugin nebo šablonu testovat, případně čekáme na nějaký impuls, abychom je přepnuli do aktivního stavu. Obecně tedy platí, že na webu mají být pouze aktivní a aktualizované komponenty, ale jsou situace, kdy tomu tak není. Toto doporučení je tedy potřeba chápat v daném kontextu (produkční web vs pracovní kopie).

Naplánovaná událost je zpožděna

Naplánovaná událost, wf_scan_monitor, nebyla včas spuštěna. Web stále funguje, ale může to znamenat, že plánování příspěvků nebo automatické aktualizace nemusí správně fungovat.

Tady neběží cron, příčinou může být:

pokud máme WPCron, tak se po návštěvě nespustil požadavek (viz výše),
pokud máme serverový cron, neběží ve správným frekvencích (schedule),
nemáme cron vůbec, tzn. není aktivní ani WPCron, ani serverový

Zastaralý SQL server

Jak z hlášení vyplývá, je potřeba, aby hosting updatoval databázový stroj na vyšší verzi. To je asi mimo vaše kompetence a pokud s tím hosting dělá drahoty, jste na nesprávném hostingu.

Chybí minimálně jeden doporučený modul

PHP je modulární jazyk, pro běh WordPressu jsou potřeba některé moduly, aby mohl správně fungovat. Typicky je to již zmiňovaný cURL, ale třeba taky openssl pro podporu zabezpečeného přenosu dat nebo mbstring pro podporu textů v UTF8.

Volitelný modul - imagick, není nainstalován nebo byl deaktivován.

Pokud chybí imagick, ještě to nemusí být neštěstí, obvykle bývá místo něj k dispozici gd, oba pracují s obrázky. Ten druhý obvykle stačí, ale fajnšmekři říkají, že při zmenšování a dalších operacích obrázky příliš komprimuje a degraduje, takže je lepší použít ImageMagick.

Mezipaměť stránek nebyla zjištěna, ale doba odezvy serveru je v pořádku a také: Měli byste použít trvalou mezipaměť objektů

Mezipamětí se myslí cachovací mechanismus v nebo pro PHP. Samotné PHP obsahuje cachování pomocí APCu, ostatní lze spustit jako samostatnou službu na serveru a pak je využít ve WordPressu pomocí pluginu. V tomto případě se domnívám, že jde o objektové cache, kde se data ukládají ve tvaru klíč:hodnota. Čili se tím zrychlují (resp. předcházejí) dotazy do databáze.

Zdá se, že hosting podporuje následující služby ukládání objektů do mezipaměti: APCu.

Pokud vám web hlásí něco podobného, pak vám jede na slanou vodu a brzy se zadře. Je to sice velmi nepravděpodobné, protože „všechny“ hostingy používají nějakou cache, ale přesto je dobré toto tvrzení ověřit. Další často používané cachovací vrstvy jsou memcached, Redis (ten chtějte!) a další (které ale na běžném hostingu nejspíše nenajdete).

Pozor, tento způsob cachování vám automaticky nezrychlí web na mobilu, ale spíše práci v backendu, protože ulehčí databázi. Pro rychlejší stránky frontendu spíše potřebujete celostránkovou cache jako Varnish.

Potřebujete zrychlit web, který je pomalý v administraci? Docela si troufám, napište, určitě vám dokážu pomoct.

Úspěšné testy a správné nastavení

Na konci stránky najdete tlačítko, po jehož rozkliknutí se zobrazí úspěšně provedené testy. Tady je svět v pořádku.

Dokumentaci ke stavu webu najdete na portálu wordpress.org, jako mnoho jiných informací.

Rychlá analýza webu

Zrychlení backendu