Zvolené téma obsahuje celkem 7 odpovědí. Do diskuze (2 účastníci) se naposledy zapojil uživatel 
-
Příspěvky
-
Zdravím, mám drobný problém. Na webhostingu Forpsi, kde máme web http://www.vlasyaucesy.cz, kde máme nainstalovaný wordpress mi občas dochází k následující chybě.
500 Internal Server Error
The server encountered an internal error and was unable to complete your request.
Error message: Premature end of script headers: admin.phpPřípadně post.php atd …
Z Forpsi mě odpálili na znalostní databázi :) https://support.forpsi.com/KB/a2438/500-internal-server-error.aspx, kterou jsem si předtím našel. To nastavení 775 samozřejmě mám a do htaccessu se mi zase tak moc sahat nechce, protože ve wordpressu používám cache od WP Rocket a tam jsou samozřejmě jejich nastavení.
Zajímavé na tom je to, že ten problém se objevuje jenom někdy a většinou při ukládání nového postu, kde je větší množství nových tagu. A i když to spadne na tu chybu 500, tak v konceptech ten post zůstane, jenom tam nejsou uložené ty tagy. tak je znovu vložím a uložím a pak už to všechno funguje. A jsou případy, kdy ten post uloží tak jak má.
Přikládám pro ukázku httaccess
Forpsi mělo s touto chybou problém už před lety, řešilo se to např. zde. Údajně mají někde v administraci nějaké tlačítko na hromadné opravení práv souborů.
Problém se souborem
.htaccessmůžete vyloučit, když ho na chvíli přejmenujete, odpojíte cachovací plugin a zkusíte něco publikovat :-) Ale myslím, že by tam byl problém neustále, tedy nejen při publikování příspěvků…Ale chyba 500 se často stává také v případě, kdy dojde k problémům s výkonem (aneb narážíte na PHP limity na serveru – paměť, počet procesů, timeout, atd), což mi asi přijde nejpravděpodobnější. Pokud se dobře pamatuji, tak používáte různé náročné pluginy typu WPML a během publikování příspěvku se může spouštět mnoho různých skriptů. Jen v defaultním nastavení WordPressu se např. pinguje Google a další služby – neposíláte příspěvky třeba nějak automaticky na sociální sítě nebo něco podobného? Bude to asi potřeba debuggovat (aneb co se spouští) a případně částečně odpojovat (můžete zkusit deaktivovat i některé “podezřelé” pluginy). Možná jsou štítky v databázi ještě nějak přiřazovány, automaticky překládány, nevím, zkuste se zamyslet nad používanými pluginy, zda se tam nemůže dít něco náročného…
Máte k dispozici
error.logs chybovými hláškami? Není tam třeba něco zajímavého, co by mohlo nějak souviset?Mimochodem, jaké máte zkušenosti s pluginem WP Rocket? Z některých testů vyšel velmi dobře…
Díky za reakci, přivedla mě na jednu myšlenku týkající se právě WPML a to subpluginu WPML String Translation s kterým jsem míval problémy, právě v souvislosti s výkonem. Ona je to část WPML určená na překlady všech věcí, které nespadají dovnitř postu, pages atd. a on opravdu dokáže excelentně žrát výkon. Oni se ve WPML prsili, že ta nová verze 3.2 by na tom měla být výrazně lépe, ale nevim nevim, nějak mi to připadá stejné :) Ale i tak mám pořád nějaký pocit, že by se to mohlo motat kolem timeoutu. Ono se totiž nakupilo více věcí – změnili jsme hosting, změnili jsme cache a při té změně hostingu jsem zapnul zpět všechny pluginy a to včetně WPML String Translation, který jsme měl předtím vypnutý právě kvůli výkonu, ale tam to vedlo ke zpomalování stránek v administraci, což jsem teď neměl. Tak uvidíme co to udělá a pak dám vědět.
WP Rocket – ten náš server je celkem dost omalovaný, obsahuje velké množství obrázků, jenom v Nextgen Gallery máme cca 8000 fotek (220 galerii) a máme cca návštěvnost 3000 users denně v CZ a 1000 v SK a děláme cca 13-15 tisíc shlédnutí denně, to do toho nepočítám listování v Nexten-Gallery, kde my ty galerie máme vlastně v každém článku, protože využívám možnost zobrazení všech obrázků z daného článku v Nexteg Gallery. To jenom na úvod, aby bylo jasno, že to asi celkem žere výkon. Když jsme přešli na WordPress (kdysi jsme používali na jiném webu OpenCMS, ale ten je podle mě za zenitem a to co nabízí WP se s tím nedá srovnat) tak jsem postupně přešel od WP Super Cache, přes W3 Total Cache (pak i v komvbinaci s Varnish cache) až právě k WP Rocket.
1. WP Super Cache (WPSC) – velmi příjemná, vcelku jednoduché nastavení a po internetu na ni najdete kýbl návodů, které jsou obecně všechny stejné. Bohužel s přibývajícím nárůstem návštěvnosti tak trochu ztrácela dech a navíc v kombinaci s WPML měla problém s aktualizací stránek na druhém jazyku. Laicky řešeno, když jste udělal publish postu a on se dostal na homepage, tak v CZ verzi bez problémů, ale v SK verzi to prakticky neudělala nikdy a člověk musel flushnout celou cache, což samozřejmě bylo přes den, kdy tam je dost velký tlak velký problém. Takže to vedlo k tomu, že se překlady dělaly do “zásoby” a flush se dělal v noci. Nicméně, nikdy jsem nepřišel na to, jak to udělal, aby ten flush udělal automaticky. On ho sice měl nastavený, ale nikdy ho vlastně neprovedl. A co se týká supportu tak čistá nula, tam píšete prostě do tmy.
2. W3 Total Cache (W3TC) – on je to velmi zajímavý plugin s neuvěřitelným množstvím nastavení atd. Nicméně to je právě ten kámen úrazu. Já jsem uživatelský kodér, já si zprovozním WP, jsem schopen ohnout si css, sem tam něco v php, ale o těch systémových provozech toho opravdu moc nevím. A navíc, W3TC v té verzi zdarma trpěla vlastně podobnými neduhy jako WPSC, takže pokud jste si nenastavil věci v apache a k tomu jsme nakonec došli s Varnish, tak ten výkon byl takový všelijaký. A opět kombinace s WPML a problém aktualizace stránek po vypublikování postu. On prostě žádný z těch pluginů s tím WPML tak moc nepočítá. Oni sice píšeou u WPML, že jedou na W3TC, ale já moc nestudoval ty jejich lokalizace. A když jsme dodali na server Varnish, tak rychlost perfektní, ono to jde přece jenom znát, že se to najednou ukládají ty věci na disk a on ten WP si na to potom bleskově sáhne. Ale za prvé to neuděláte na běžném hostingu, za druhé to neuděláte bez znalostí, které já neměl a musel to dělat kolega a za třetí máte problém to z těch cache “vybít” :). Zkoušel jsem pluginy na flush Varnishe, ale nějak to nefungovalo a ten problém byl o to větší, že takto se zakešovaly i seznamy článků v kategoriích atd. Takže možná, že W3TC bude pro spousty lidí dostačujících, protože je zadarmo, ale ona to stejně není tak úplně pravda, protože když z ní chcete vymáčknout maximum, tak tam stejně skončíte na těch jejich placených add-onech. A samozřejmě, pokud si nekoupíte ten placený support tak píšete na lampárnu, což já nikomu nevyčítám, chápu, že musí z něčeho žít a ne trávit život na wp supportu a nic z toho nemít. Ale nějak jsem cítil, že to W3TC není úplně to co bych chtěl, že je to na mě hlavně moc složité, komplikované a “přechlívkované” :D.
No a protože mi to lezlo krkem se pořád o to starat a nemít čas na jiné věci, tak jsem pátral a našel WP Rocket.
3. WP Rocket – nechci aby to vyznělo, že je to bez chyby, ale ani oni si to nemyslí ani ti vývojáři. Za prvé jde vidět, že je to prémiový produkt, protože hned jak si jej koupíte, tak se vám ozvou vývojáři s tím, že při jakémkoliv problému je máte kontaktovat. Po týdnu opět kontakt s tím, jaké mám zkušenosti a jestli něco nepotřebuji atd. Prostě ta starostlivost je obrovská. Co je úžasné, tak je to, že nastavení je tam prakticky na jednu stranu (viz přiloha) a to na té jedné straně je pár položek k zakliknutí, což pochopí každý. Na dalších stránkách už je jenom nastavení při používání CDN (zatím nepoužíváme, ale do budoucna budeme, tak jsem zvědav), na další rozšířené možnosti typu zakázat určité stránky z cache atd. Zatím jsem neměl důvod použít. Výkon je opravdu tak jak psali zatím nejlepší ze všech. ta rychlost na stránkách je bez problémů při jakékoliv návštěvnosti, velmi rychle se ty stránky zakešují po flushnutí atd. Vynikající kompatibilita s WPML, naprosto dokonalá. Prostě jakmile článek vypublikuji, tak je okamžitě na těch stránkách a to jak na homepage, tak na seznamu kategorií atd. Je naprosto jedno v jakém jste jazyku. jakmile udělám úpravu v postu/pages a dám aktualizovat a Clear cache, tak je všechno opraveno a to na jakékoliv úrovni, tzn. třeba i změna url, titulku atd. Už jenom kvůli tomuto bych nikdy ten plugin za nic jiného nevyměnil. Jsou zde problém s minifikací CSS a Javastriptu, ale tady je ten problém spíše na straně šablony jako takové a bude to chtít doladit, ale k tomu jsem se zatím nedostal.
Uff, trochu jsem se rozepsal, snad to bude stačit, kdyby cokoliv tak se ptejte.
Attachments:
Uffff, díky moc za příspěvek a podrobné vysvětlení! Také se na WP Rocket chystám (a podle popisu to vypadá na budoucího favorita), ale zatím ještě nebyl čas :-)
Podařilo se problém s chybou 500 při publikování příspěvku nakonec vyřešit? WPML String Translation se mi také moc nezdá a nepoužívám ho. nedávno jsem potřeboval provozovat administraci ve více jazycích a WPML místo aby automaticky stáhnul příslušné jazykové verze, tak umí překlady pouze importovat do databáze, se kterou pak pracuje, což mi přijde dost zbytečné. Rozumím tomu, že to chce mít někdo upravené podle sebe, ale jinak to prostě zatím bohužel nefunguje…
WP Super Cache bohužel nemá žádnou podporu, ale problémy je možné většino vyřešit (musí se ale detailně debugovat). W3 Total Cache je na tom dost podobně, placenou verzi jsem nikdy nezkoušel…
Na chvíli jsme se odmlčel, protože jsem se snažil odhalit ten problém a tedy opravdu moc nevím. Vím :D :D tedy jednu věc a to, že to vždy spadne ve chvíli kdy ukládám post včetně tagu. Obecně má hrozný problém s ukládáním tagu, protože, když ten post ukládám z editoru a přidám k tomu postu tagy, tak to na 100% spadne. Když to uložím bez tagu, tak to projde a to vcelku rychle. Pak jdu do seznamu postu, tam udělám quick edit a tam po vcelku dost hrozné době ty tagy uloží.
Potkal jste se někdy s tím? Mám podezření na problém s databází, protože když to padne, tak všechno uloží (title, text, images), ale neuloží slug – zvláštní. Ale tam si fakt netroufám dělat žádné zásahy, protože do toho vůbec nevidím. Jenom pro info, v této chvíli tam mám cca 4400 tagu (2600 ceských, 1800 slovenských). Jo a zkoušel jsem na radu s Forpsi se dívat na databázi, když dochází k ukládání a žádný proces mi tam nezůstane viset. Takže any idea? :)
Podle mě to způsobuje nějaký plugin (osobně trochu podezřívám WPML), zkoušel jste je všechny deaktivovat a pak něco publikovat? Počet štítků by neměl být problém, také jich tu mám na webu tisíce a žádné zpomalení nepozoruji… Vím, že se v tom asi moc nechcete hrabat, ale chtělo by to prověřit, který plugin za to může (před pokusy zazálohovat). Asi by neměl být problém pokusit se debugovat akce, které probíhají při publikování/aktualizaci příspěvků, ale to už bych potřeboval přístupy… Mohli bychom pak třeba logovat funkce a SQL dotazy, které tam probíhají. Může tam docházet třeba k nějakému zacyklení SQL dotazů, poslední WordPress obsahuje mnoho změn v oblasti taxonomií a třeba je WPML ještě všechny pořádně nepobral…
Problém je pouze při publikaci nového příspěvku? Co když ho pak třeba upravujete a odeberete nějaké štítky a jiné přidáte?
Máte k dispozici
error.logs chybovými hláškami?V této chvíli to řeším tak, že založím post texty + images ale bez tagu. Toto uložím a to projde naprosto bez problémů a to jak ukládání konceptu, tak publikování. A pak hned na to přidám tagy a zatím (zkoušeno na 3 článcích) to vždy prošlo. :) Ono já taky podezřívám WPML :D – skoro vždy za podobnou chybou to WPML bylo a oni s tagy už párkrát bojovali, naposledy kdy docházelo ke zdvojování tagů. Takže ještě chvilku to budu pozorovat a pokud se to bude pořád objevovat tak se ozvu.
Co se týká úprav, editace, mazání atd. tak tam problém není. Tam vznikne ten problém ve chvíli, kdy se ukládá koncept / publish – ale já prakticky vždy nejdříve post uložím jako koncept a teprve po tom co si jej prohlédnu, tak dělám publish – a s tím ukládáním se ukládají zároveň tagy.
Co se týká error logu jak nejlépe na to? :) Já to nikdy moce neřešil, to už je na mě trošku “vysoká škola” :) K Apache přístup nemám, k MySQL ano, přes web phpMyAdmin. Díval jsem se, že na error log jsou i nějaké pluginy, ale jaký nejlépe netuším.
Každopádně velké díky za pomoc.
Chtěl bych se vrátit k mému problému, v poslední době se mi kromě výše uvedené chyby začala objevovat chyba.
503 Service temporarily unavailable
There is no available fastcgi process to fullfill your request.Už jsem i všechny pluginy “ořezal na kost” :) co nebylo vyloženě nutné jsem zahodil, ale ten problém pořád přetrvává. A když jsem tak bádal tak mě napadlo, jestli ten problém nemůže způsobovat málo paměti, na tom hostingu je memory_limit 128 MB a když jsem se dívat na WPML tak oni píšou že 128 MB je základ. Co si o tom myslíte? Bohužel si nejsem jistý, že mi na Forpsi ten memory_limit na tom webhostingu zvednou.
Pokud chcete odpovědět na toto téma, musíte se nejdříve přihlásit.