it-swarm-eu.dev

Jak odstranit podivné chyby 404 v wp-admin?

Provozuji stránku WordPress s asi 70 aktivními pluginy.

Každopádně dostanu náhodnou chybovou stránku ("Not Found", i když jsem nezkontroloval hlavičky, zda je to 404) na stránce /wp-admin/, která se vynoří z ničeho.

Jednoduše se pokusíte znovu vyřešit chybu, ale je to nepohodlné, pokud se chyba stane během upgradu pluginu (protože automatická reaktivace selže). Myslím, že stejný problém je zodpovědný za to, že některé moduly na panelu se někdy nenačítají.

Vzhledem k tomu, že seznam pluginů, které jsem nainstaloval , ví někdo o problémech s nebo mezi některými z nich, které by mohly způsobit tento problém?

Upravit:

Informace o hostingu: DreamHost; Domnívám se, že server provozuje vlastní sestavení Debianu s Apache httpd

8
dgw

měl jsem problémy celý den s tím, co se zdálo být 404 selhání.

mimochodem, právě jsem dokončil chatování s osobou s podporou Dreamhost, která mi řekla, že uživatelský účet, který mám s nimi, bil limity pro paměť procesních paměti (všechny procesy) a to bylo to, co způsobovalo podivné, zdánlivě htaccess-související problémy. Dostával jsem občasné chyby 404 ze souboru htaccess, který neměl být vůbec volán! byl to snův strašidelný dům.

zdá se, že proces zabíjení robot, který Dreamhost používá, zabije webový proces uprostřed a pak z nějakého důvodu (nyní zombie) Apache se ve skutečnosti pokusí dokončit svou práci (dělá to, co je v jeho silách, aby se čistě vymanil z bezohledného konce do subrequestu). je můj nejlepší odhad). hodí chybu 500 do hlavního http protokolu, ale po tom skutečně vypne podmínku přepisu a pravidlo, které by nikdy nemělo být spuštěno (pomocí standardního souboru -f a adresáře -d souboru htaccess výše) - a to neznamená nepište nový záznam do protokolu! Nový požadavek (neviditelný člověk) pak spustí indexový soubor v posledním řádku souboru htaccess

dejte si pozor na limity zdrojů v základních účtech Dreamhost! pokud půjdete přes jejich limity, a máte htacess s mod_rewrite řádky uvidíte zvláštní věci, které jsou vhodné pouze pro halloween noc - neviditelné muže, strašidelné 404s! nemrtvé procesy! zombie Apache! htaccess pohybující se sám! yikes!

doufám, že to pomůže vyhnout se některým hodinám bolesti.

6
sophistry

Jediný způsob, jak ladit, je zakázat vždy jeden plugin, pokaždé, když se pokusíte problém reprodukovat dříve, než zakážete jiný plugin. Začněte s pluginy, které mají co do činění s administrací WP, pak se přesuňte na běžné téma pluginy, widgety a podobně.

Prohlédněte si stránku "Not Found", která vám byla doručena lépe (procházejte pomocí Opery a otevřete panel Info, který vám ukáže hlavičky, případně procházíte prohlížečem Firefox a máte povolený Firebug s panelem "Net") a proveďte vyhledávání prostřednictvím všech vaše pluginy, abyste zjistili, zda by jim to mohlo sloužit přímo. Pokud ne, podívejte se do protokolu webového serveru a zjistěte, jaký přesný zdroj není schopen sloužit; plugin může dělat nějaké přepracované přesměrování nebo přepisování, takže to nemusí být nutně URL, které vidíte ve vašem prohlížeči, který způsobuje, že 404.

4
Asbjørn Ulsberg

Dokážu se týkat pouze mé vlastní zkušenosti, a zatím jsem nenašel "jednoznačné" pravidlo, které by opravilo všechny otázky při jednom tahu.

Hlavní problém s nastavením DreamHostu je v tom, že ve věčném boji o udržení spotřeby paměti na minimu to znamená zbavit se co nejvíce funkcí - konkrétně vše, co sníží šířku pásma (dobré pro návštěvníky!) Nebo CPU (dobré pro server, ale DreamHost nekontroluje spotřebu CPU tak agresivně, jak kontroluje RAM). Například to znamená zbavit se gzip'ed HTML + CSS (který bude spotřebovávat CPU + RAM) nebo některý z několika Minify pluginů (které budou spotřebovávat také RAM). Čím sofistikovanější je mezipaměť (jsem rád, že používám W3 Total Cache, nebo alespoň WP Super Cache), tím více bude také spotřebováno RAM.

Podobně mnoho pluginů, které omezují počet MySQL dotazů pro zlepšení výkonu, bude místo toho spotřebovávat RAM. Takže nalezení kompromisu, kde můžete stále udržovat vaše stránky v odpovědi s dobrým výkonem a zároveň se vyhnout spotřebě drahocenných RAM je těžký úkol!

Podle mých nejlepších výsledků na rušných stránkách je zatím třeba zrušit zaškrtnutí stránky Optimalizace rychlosti stránek a Extra Web Security, které zřejmě spotřebovávají spoustu paměti RAM a místo toho se spoléhají na kombinaci s vyrovnávací pamětí W3 Total Cache a Cloudflare. Cloudflare bude efektivně dělat totéž jako modul "Extra Web Security", ale protože běží mimo DreamHost, je to v pořádku. W3 Total Cache spotřebovává spoustu paměti, ale jakmile jsou stránky staticky uloženy lokálně, Cloudflare je velmi efektivně ukládá do mezipaměti - takže můžete při úpravách příspěvků získat 404/500, alespoň vaši návštěvníci s nimi nebudou mít zkušenosti (Cloudflare také může poskytovat statické stránky i když DreamHost dává 404 nebo 500).

Také díky tento článek jsem zjistil, že FastCGI používá více RAM než 'normální' CGI. A vzhledem k tomu, že PHP 5.3 je lepší při řízení RAM (agresivnější sběr odpadu, méně úniků z paměti), experimentálně jsem přešel na PHP 5.3 CGI (ne FastCGI) bez optimalizace rychlosti stránek ani Extra Web Security, spoléhající na W3 Total Cache + Cloudflare pro urychlení webu. Nyní je backoffice pomalejší (více spotřeby CPU!), Ale alespoň nevidím 404/500 (zatím!).

Jsem stále nespokojen s touto kombinací, takže určitě budu pokračovat v nastavení Tweak DreamHost a doufám, že ještě více sníží spotřebu RAM a stále dostanu odpovídající výkon. Stejně jako @dgw řekl jsem také použít spoustu pluginů - protože potřebuji jejich funkčnost. Ne každý hostující WP s DreamHostem má jednoduché potřeby blogů; čím složitější stránky, tím více funkcí bude vyžadovat ... a to je krása WordPress, stačí použít pluginy, které opravdu potřebujete, a udržet jádro WP instalaci jednoduchou, pokud jste spokojeni s potřeb. Zásuvné moduly však nejsou nutně „špatné“ nebo těžké na webu; ale je pravda, že někteří mohou konzumovat spoustu paměti RAM ...

3
Gwyneth Llewelyn

To je jen hrubá představa: Pokud dostanete "skutečnou" chybu 404 (se sadou záhlaví), můžete prohledávat své pluginy a vyhledat funkci PHP header() a číslo 404 . To by mohlo snížit počet pluginů ze 70 na jen některé. Pak stačí zkontrolovat ty.

To lze snadno provést pomocí IDE jako Eclipse PDT, který nabízí vyhledávání specifického volání funkce PHP.

Vedle toho, ale bez záruky, že to úspěšně funguje, je napsat plugin, který zavěsí do nastavení záhlaví a pak vám dá stopu, který kód ve skutečnosti nastavuje potenciál 404 (backtrace). To by fungovalo pouze v případě, že plugin používá funkci WordPress API. První metoda hledání funkce PHP bude fungovat bez ohledu na WP API.

3
hakre

Další informace:

1) Proč tolik pluginů?

2) Jaký operační systém provozuje váš poskytovatel hostingu?

3) Jaký webserver?

4) Máte přístup k protokolům serveru httpd, zejména protokolování chyb?

5) Co říkají chybové protokoly v časovém rámci, který tyto problémy obklopuje?

(Teď, pravda, je řečeno, pokud jsme zobecnění pro "průměrné J6P běží WordPress může mít tuto přesnou otázku, mohli bychom začít tím, že nařídí řekl J6P odpovědět alespoň výše uvedených 5 otázek ...)

2
ZaMoose