Cum să elimini erorile ciudate 404 în wp-admin?

Singura modalitate de a depana această problemă este să dezactivezi câte un plugin pe rând, încercând să reproduci problema înainte de a dezactiva următorul plugin. Începe cu pluginurile care au legătură cu administrarea WordPress, apoi treci la pluginurile obișnuite pentru teme, widget-uri și altele asemenea.

Analizează mai atent pagina "Not Found" pe care o primești (navighează cu Opera și deschide panoul Info care îți va afișa antetele sau folosește Firefox cu panoul "Net" din Firebug activat) și caută în toate pluginurile tale pentru a vedea dacă vreunul servește direct acea pagină. Dacă nu, verifică jurnalul serverului web pentru a afla exact ce resursă nu poate fi servită; un plugin ar putea să facă o redirecționare sau rescriere complexă, așa că nu neapărat URL-ul pe care îl vezi în browser este cel care provoacă eroarea 404.

Acesta este doar o idee aproximativă: Dacă primiți o eroare 404 "reală" (cu antete setate), atunci puteți căuta prin plugin-urile dumneavoastră și să căutați funcția PHP header() și numărul 404. Acest lucru ar putea reduce numărul de plugin-uri de la 70 la doar câteva. Apoi trebuie doar să le verificați pe acelea.

Acest lucru poate fi făcut ușor cu un IDE precum Eclipse PDT care oferă căutare pentru un apel specific de funcție PHP.

Pe lângă aceasta, dar fără garanție că va funcționa cu succes, este să scrieți un plugin care se conectează la setarea antetelor și apoi vă oferă urmărirea care cod setează efectiv un potențial 404 (backtrace). Acest lucru ar funcționa doar dacă plugin-ul utilizează funcția API WordPress. Prima metodă de a căuta funcția PHP va funcționa indiferent de API-ul WP.

Pot să relatez doar experiența mea personală, și până acum, nu am găsit o regulă "definitivă" care să rezolve toate problemele dintr-o singură lovitură.

Principala problemă cu configurația DreamHost este că, în lupta eternă de a menține consumul de memorie la un nivel minim, înseamnă eliminarea cât mai multor funcționalități posibile — și anume, toate cele care ar reduce lățimea de bandă (bun pentru vizitatori!) sau CPU-ul (bun pentru server, dar DreamHost nu controlează consumul de CPU la fel de agresiv cum controlează RAM-ul). De exemplu, asta înseamnă eliminarea HTML-ului și CSS-ului comprimat cu gzip (care ar consuma CPU + RAM) sau a oricăruia dintre pluginurile de minimizare (care ar consuma și ele RAM). Cu cât cache-ul este mai sofisticat (eu prefer să folosesc W3 Total Cache, sau cel puțin WP Super Cache), cu atât va fi consumat mai mult RAM.

În mod similar, multe pluginuri care limitează numărul de interogări MySQL pentru a îmbunătăți performanța vor consuma în schimb RAM. Așadar, găsirea unui compromis în care site-ul tău răspunde în continuare cu performanțe bune, evitând consumul prețios de RAM, este o sarcină dificilă!

Până acum, cele mai bune rezultate pe site-uri aglomerate le-am obținut prin dezactivarea Optimizării Vitezei Paginilor și a Securității Web Suplimentare, care par să consume foarte mult RAM, și prin folosirea în schimb a unei combinații între W3 Total Cache și Cloudflare (serviciu gratuit de proxy invers). Cloudflare va face efectiv același lucru ca modulul "Securitate Web Suplimentară", dar deoarece rulează în afara DreamHost, este în regulă. W3 Total Cache consumă multă memorie, dar odată ce paginile sunt stocate static local, Cloudflare le va cache-ui foarte eficient — așa că s-ar putea să primești erori 404/500 în timp ce editezi postări, dar cel puțin vizitatorii tăi nu le vor experimenta (Cloudflare poate servi pagini statice chiar dacă DreamHost returnează un 404 sau un 500).

De asemenea, datorită acestui articol, am aflat că FastCGI folosește mai mult RAM decât CGI-ul 'normal'. Și deoarece PHP 5.3 este mai bun la gestionarea RAM-ului (colectare mai agresivă a gunoiului, mai puține scurgeri de memorie), am trecut experimental la PHP 5.3 CGI (nu FastCGI) fără Optimizarea Vitezei Paginilor și fără Securitatea Web Suplimentară, bazându-mă pe W3 Total Cache + Cloudflare pentru a accelera site-ul. Acum backoffice-ul este mai lent (consum mai mare de CPU!), dar cel puțin nu mai văd erori 404/500 (până acum!).

Încă nu sunt mulțumit de această combinație, așa că cu siguranță voi continua să ajustez setările DreamHost în speranța de a reduce și mai mult consumul de RAM și de a obține totuși performanțe adecvate. Precum @dgw a menționat, și eu folosesc multe pluginuri — pentru că am nevoie de funcționalitățile lor. Nu toți cei care găzduiesc WordPress pe DreamHost au nevoi simple, de blogging; cu cât site-ul este mai complex, cu atât va necesita mai multă funcționalitate... și aceasta este frumusețea WordPress, trebuie doar să folosești pluginurile de care ai cu adevărat nevoie și să păstrezi instalarea de bază simplă dacă ești mulțumit cu puține nevoi. Pluginurile, totuși, nu sunt neapărat "rele" sau grele pentru site; dar este adevărat că unele pot consuma mult RAM...

Mai multe informații necesare:

1) De ce atât de multe plugin-uri?

2) Ce sistem de operare rulează pe serverul de hosting?

3) Ce server web folosești?

4) Ai acces la jurnalele serverului httpd, în special la jurnalele de erori?

5) Ce afișează jurnalele de erori în perioada în care apar aceste probleme?

(Acum, dacă generalizăm pentru "utilizatorul mediu WordPress care ar putea avea această întrebare exactă, am putea începe prin a-l îndruma să răspundă la cele 5 întrebări de mai sus...)