Nejčastěji řešené problémy WordPressu

Pokud po nějaké změně v aplikaci, typicky po automatické či ruční aktualizaci jádra WordPressu nebo nějakého jeho doplňku, nebo ruční úpravě kódu aplikace, nastane situace, kdy je celý web nebo nějaká jeho část nedostupná a vypisují se při jejich načtení různé kritické chyby, např. "Na webu došlo k závažné chybě", případně se objeví standardní chybová stránka s kódem 500 (Internal server error), je prvním krokem v rámci obecného řešení zapnutí logování PHP chyb. Z uloženého logu je pak většinou možné identifikovat, ve které části kódu aplikace problém nastává.

Nejčastěji je problém způsoben nekompatibilitou jádra WordPressu a nějakého doplňku či více doplňků. Případně tím, že WordPress provozujete na verzi PHP/MySQL, pro které nová verze WordPressu nebo jeho doplňků není připravena či již podporována. A nebo může být chyba způsobena tím, že se aktualizace provedla jen částečně a nebyla dokončena kompletně.

Řešení se pak odvíjí od toho, která ze zmíněných věcí je příčinou. Opět obecně můžeme doporučit zkusit následující věci (před každou úpravou doporučujeme provést zálohu aktuálního obsahu webu):
 

• pokud aktualizace jádra WordPressu způsobí nefunkčnost nějakého doplňku, lze konkrétní plugin/šablonu buď dočasně deaktivovat nebo odinstalovat. Případně, pokud doplněk nutně potřebujete, je možné se vrátit k předchozí funkční verzi WordPressu pomocí pluginu WP Downgrade, který vyhledáte a nainstalujete standardní cestou v administraci. Současně doporučujeme dočasně zakázat automatické aktualizace
• naopak, pokud k chybě dochází pouze po aktualizaci nějakého doplňku, lze se k jeho předchozí verzi vrátit pomocí pluginu WP Rollback
• v krajním případě, kdy se již do administrace není možné dostat ani vypnutím problematického doplňku, ani vrácením se k předchozí verzi kódu po jeho ruční úpravě, lze celou aplikaci obnovit ze zálohy. Pokud nemáte vlastní novější zálohu, můžete k obnově využít tu naši. Většinou by mělo stačit obnovit soubory aplikace, o aktuální data v databázi tedy nepřijdete

K pomalému načítání WordPress aplikace může docházet z celé řady důvodů. Mezi ty nejčastější, které jsou způsobeny samotnou aplikací a jsou tedy neovlivnitelné z naší strany, patří podle našich zkušeností tyto:

• využívání zbytečně velkého množství doplňků
• nevhodně zvolený nebo nakonfigurovaný doplněk (často paradoxně i ty, které by měly načítání WordPressu zrychlit, např. různé cachovací pluginy)
• množství provozních dat, pro které není aplikace dostatečně optimalizovaná (což vede např. k pomalému vykonávání dotazů do databáze) nebo pro ně není dostatek výpočetních prostředků na serveru
• načítání zdrojů nadměrné velikosti (typicky obrázků s nevhodným rozlišením, neoptimalizovaného JavaScriptu apod.)
• načítání části stránek z pomalých nebo nedostupných externích zdrojů (typicky prvky sociálních sítí, fonty, různé API apod.)
• aplikace neoptimalizovaná pro vyšší návštěvnost, tedy pro zpracovávání většího množství paralelních přístupů
• nevhodně nastavené spouštění WP Cronu
• neoptimální práce se sezeními (sessions)

Konkrétní příčinu zpomalení by měl vždy identifikovat primárně autor nebo správce aplikace. V případě, že mu k identifikaci nebudou stačit statistiky, logy, výpis procesů v klientské sekci, ladící výpisy samotné aplikace apod., může se obrátit na zákaznickou podporu prostřednictvím formuláře pro autorizovaný požadavek v klientské sekci s žádostí o prověření.

Dlouhé načítání WordPress webu s následným zobrazením chybové stránky s kódem 503 je typicky způsobeno vyčerpáním limitu počtu PHP procesů na serveru. Příčin vyčerpání může být celá řada, všechny podstatné informace lze nalézt v naší nápovědě na stránkách Chyba 503 a Kolik domén mohu na serveru provozovat.

Konkrétní příčinu by měl identifikovat autor nebo správce aplikace. V případě, že mu k identifikaci nebudou stačit dostupné statistiky, logy, výpis procesů v klientské sekci, ladící výpisy samotné aplikace apod., může se obrátit na zákaznickou podporu prostřednictvím formuláře pro autorizovaný požadavek v klientské sekci s žádostí o prověření.

Doporučeným a dlouhodobě nejspolehlivějším řešením problému je optimalizace aplikace, a to jak z hlediska paměťové náročnosti skriptů, tak z hlediska celkového výkonu. V případě, kdy aplikaci optimalizovat dále nejde a příčinou problémů je výhradně zvýšená návštěvnost, nebo v případě, kdy úpravy aplikace vyžadují lidsky a finančně neúnosně zvýšené náklady, je možným řešením navýšení prostředků serveru. O jejich navýšení stačí požádat prostřednictvím formuláře pro autorizovaný požadavek v klientské sekci.

Stránka s chybovým kódem 403 se může zobrazit z těchto základních důvodů:

1. v klientské sekci není ve správě (sub)domény povoleno používání souboru .htaccess a proto se neaplikují v něm nastavená rewrite pravidla (v naší oneclick instalaci je použití .htaccess povoleno automaticky)
2. v prostoru domény není nahrán indexový soubor nebo je aplikace umístěna do nějakého podadresáře namísto hlavního adresáře
3. požadavky jsou blokovány nějakým bezpečnostním pluginem WordPressu, případně nějakým pravidlem v souboru .htaccess nebo v konfiguraci serveru

V případě, že z nějakého důvodu chcete smazat plugin využívaný ve Vaší WordPress aplikaci, standardní cestou je v její administraci v sekci Pluginy plugin deaktivovat a následně odinstalovat.

Pokud tento postup nelze použít (např. se kvůli nějaké chybě vůbec do administrace nepřihlásíte), je možné plugin vypnout přejmenováním jeho adresáře na serveru v prostoru Vaší domény v adresáři wp-content/plugins a to standardně přes (S)FTP protokol. Poté jej již standardně odinstalujte přes zpřístupněnou administraci.

Pokud nějaká součást aplikace (plugin nebo část šablony) není kompatibilní s verzí PHP/MySQL na serveru a způsobuje a zobrazuje chybu, která vážně ovlivňuje fungování aplikace, lze to řešit několika způsoby:

• pokud se jedná o plugin, který pro funkčnost aplikace není nezbytně nutný, lze jej deaktivovat či úplně odinstalovat
• pokud je funkčnost pluginu/šablony pro aplikaci nezbytná, je často možné je nahradit nějakou alternativou se stejnou nebo podobnou funkčností
• plugin lze deaktivovat dočasně a vyčkat na jeho opravu - aktualizaci ze strany autora, případně mu pro urychlení opravy chybu nahlásit
• v klientské sekci si pro (sub)doménu, na které je aplikace umístěna, pro otestování přepnout řadu PHP na tu, pod kterou plugin i zbytek aplikace bude fungovat. Po úspěšném otestování lze pak doménu přesunout na webserver s funkční řadou PHP/MySQL.

Pokud se při pokusu o uložení změn obsahu po vytvoření nové stránky nebo editaci stávající v administraci objeví chyba "400 (Bad Request)" (nebo se stránka načítá nekonečně dlouho), může být na našich serverech příčinou některé z pravidel aplikačního firewallu příslušného webserveru. Takovou zkušenost máme např. u klientů, kteří používají plugin Oxygen Builder.

Pro ověření, že tomu tak je a případnou deaktivaci pravidla, stačí kontaktovat naši zákaznickou podporu prostřednictvím formuláře pro autorizovaný požadavek v klientské sekci a připojit do požadavku popis problému.

WordPress automaticky všechny příchozí požadavky na aplikaci přesměrovává na její cílovou adresu, která je definována v nastavení. Pokud je např. v konfiguraci jako URL webu nastaveno https://www.vašedoména.koncovka a požadavek přijde na http://vašedoména.koncovka, WordPress automaticky provede přesměrování.

Toto chování má ale několik nevýhod. Jednak může zpomalovat načítání webu v prohlížeči návštěvníka. Proto doporučujeme přesměrování na cílový tvar nastavit už na úrovni webserveru (který přesměrování provádí mnohem rychleji než koncová WordPress aplikace), nastavení lze provést v klientské sekci ve správě dané domény v záložce Webserver a tam dále přes editaci zvolené (sub)domény z přehledové tabulky. v sekci Přesměrování / Alias. Lze tam odděleně nastavit přesměrování z http na https (a opačně) a z varianty bez www. na variantu www. (a opačně).

V některých případech může nastavení aplikace kolidovat s přesměrováním, nastaveným ať už na straně aplikace (např. v souboru .htaccess) nebo na straně serveru (v případě přesměrování nastaveného v klientské sekci), což může vést až k zacyklení přesměrování a znefunkčnění celého webu. V takovém případě se v prohlížeči návštěvníka objeví chyba "Smyčka při přesměrování" nebo podobná. V takovém případě lze problém řešit dvěma způsoby:

• buď je možné dodatečné přesměrování dočasně zrušit, v administraci WordPressu si nastavit požadovanou URL aplikace a poté přesměrování opět nastavit tak, aby odpovídalo hodnotě nastavené v aplikaci
• nebo je možné naopak upravit URL aplikace, a to ručně v databázi WordPressu v tabulce wp_options (prefix wp_ se může lišit dle nastavení aplikace) u nastavení siteurl a home tak, aby odpovídalo přesměrování nastavenému jinde

Zneužitím bezpečnostní chyby, která se často může objevit v neaktualizované verzi WordPressu či v nějakém jeho neaktualizovaném nebo nevhodně zvoleném doplňku (pluginu/šablony) může útočník napadnout aplikaci, změnit její obsah, získat data uložená v databázi a případně ji začít zneužívat k dalším nelegálním aktivitám jako rozesílání spamu, útoky na cizí servery apod.

Pokud se taková kompromitace u Vaší WordPress aplikace potvrdí, je potřeba provést popořadě všechny tyto kroky:

1. prověřit celý prostor (sub)domény na přítomnost cizího obsahu, který není součástí aplikace, a odstranit ho
2. provést aktualizaci WordPressu na poslední verzi
3. odstranit neudržované a nepoužívané doplňky
4. odstranit doplňky, u kterých jsou nahlášeny bezpečnostní chyby nebo pocházejí z pochybných zdrojů, nebo se pokusit je nahradit jinými bezpečnějšími
5. provést aktualizaci všech zbývajících pluginů a témat

Od jiného poskytovatele

V případě, že přesouváte WordPress aplikaci od jiného poskytovatele webhostingu, je potřeba v tomto směru myslet na několik věcí:

• Jiné přihlašovací údaje k databázi – na našich serverech používáme striktní konvence pro pojmenování databázi, ty se zcela určitě budou lišit od pojmenování u původního poskytovatele. Kromě importu původních dat aplikace do databáze na našem serveru je tedy většinou potřeba přihlašovací údaje změnit v konfiguračním souboru wp-config.php, konrétně v této části kódu:

  define( 'DB_NAME', 'název databáze' );
  define( 'DB_USER', 'uživatelské jméno' );
  define( 'DB_PASSWORD', 'heslo' );

  Na našich serverech je také potřeba změnit jméno/adresu databázového serveru z localhost na 127.0.0.1, tedy:

  define( 'DB_HOST', '127.0.0.1' );

• Jiná verze nebo nastavení PHP – u původního poskytovatele webhostingu mohla být využívána odlišná verze PHP nebo jeho odlišné nastavení, což v některých případech může vést k znefunkčnění aplikace nebo některé její součásti (šablony/pluginu), jejíž funkčnost je vázána na konkretní verzi nebo nastavení. Doporučujeme proto před finálním spuštěním aplikace na novém serveru funkčnost celé aplikace důkladně otestovat.

Změna názvu adresy WordPressu

• Změna názvu subdomény – v aplikaci WordPress je v jejím nastavení definována (sub)doména resp. URL adresa, na které bude web fungovat. V případě, že aplikaci přesouváte na jinou (sub)doménu, je potřeba v konfiguraci aplikace adresu změnit. To lze provést více způsoby:

  1. v souboru wp-config.php přidáním tohoto kódu:

     define( 'WP_HOME', 'https://vašedoména.koncovka' );
     define( 'WP_SITEURL', 'https://vašedoména.koncovka' );
     
     update_option( 'siteurl', 'https://vašedoména.koncovka' );
     update_option( 'home', 'https://vašedoména.koncovka' );

  2. přímou úpravou v databázi (např. přes naše webové rozhraní phpMyAdmin), konkrétně v tabulce wp_options (prefix wp_ se může lišit dle nastavení aplikace) u nastavení siteurl a home

Přesun na novější řadu PHP

U PHP pravidelně dochází k vydávání nových verzí a tomu se přizpůsobují i nové verze aplikace WordPress. Doporučujeme vždy aplikaci WordPress u nás hostovat na serverech s nejnovější podporovanou řadou PHP. Často na to nutnost upgradu na novější řadu PHP upozorní ve své administraci sama aplikace. Přes klientskou sekci si můžete funkčnost na novější řadě PHP nejdříve otestovat a poté doménu na server s novějším PHP finálně přesunout.

Přesun na jinou (sub)doménu

V případě, že aplikaci Worpdress přesouváte na jinou (sub)doménu, je potřeba tuto změnu zohlednit v jejím nastavení.

Nejčastější příčinou zobrazení chyby typu „The checksum of the file (XXX) does not match the expected checksum value“, během provádění nějaké aktualizace, je nedostatek místa na disku serveru nebo vyčerpání diskové kvóty pro danou doménu. Z toho důvodu se nedaří aktualizační soubor resp. balík stáhnout kompletní.

Řešením je uvolnění dostatečného prostoru promazáním starých nebo nepotřebných dat, případně doobjednání dodatečného prostoru přes naši zákaznickou podporu.

Pokud v administraci vytváření nových stránek či příspěvků končí touto (nebo podobnou) chybou:

Duplicate entry 0 for key 1, Duplicate entry 0 for key PRIMARY

je potřeba ověřit, že je u příslušných tabulek v databázi u primárního klíče (sloupec ID) nastaven příznak AUTO_INCREMENT. Pokud ne, je ho třeba zapnout. Úprava je určena zkušenějším uživatelům a je vhodné před ní databázi zazálohovat.

V případě že se v administraci WordPressu v sekci Nástroje – Stav webu zobrazuje upozornění obsahující výrazy "relace PHP", "REST API" a "zpětné smyčky" apod., může to souviset s používáním pluginu WP Limit Login Attempts, který jsme dříve aktivovali i v našich instalacích na jedno kliknutí (v nových instalacích je nahrazen dvěma jinými pluginy). Jedná se o doplněk, který přidává další ověření a zabezpečení na přihlašovací stránku do administrace aplikace.

Řešením je daný plugin odinstalovat a nahradit jej pluginy, které v naší instalaci máme nyní a které žádné problémy podle našich dosavadních zkušeností nezpůsobují. Jedná se o pluginy Limit Login Attempts Reloaded a WPS Hide Login.