Zdraví webu

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ší.

zdravi webu

Do této sekce se dostanete z hlavní nabídky Nástroje > Zdraví webu.

Obsah

  1. Souhrn konfigurace webu
  2. Závažné problémy
  3. Doporučená vylepšení
  4. Ú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

stav webu informace
Ukazatel kondice a tlačítko pro zkopírování informací

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 (Ctrl-v třeba ve Wordu) 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.

Počítají se velikosti adresářů
Počítají se velikosti adresářů

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.

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.

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.

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).

Ú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í.

Newsletter Rádce pro správce

Každou středu rozesíláme část svého know-how, které jsme pracně získali během posledních let. Zadarmo každému, kdo má zájem stát se zkušeným správcem WordPressu. Není určený našim zákazníkům, nýbrž našim kolegům v oboru. Vracíme tak komunitě to, co jsme získali od jiných. Podívejte se do jeho archivu.