Comment éliminer les erreurs 404 étranges dans wp-admin?

Je gère un site WordPress avec environ 70 plugins actifs.

De temps en temps, j'obtiens une page d'erreur aléatoire ("Introuvable", bien que je n'aie pas vérifié les en-têtes pour voir s'il s'agit d'un 404) sur une /wp-admin/page qui apparaît de nulle part.

Réessayer simplement résout l'erreur, mais il est assez gênant si l'erreur se produit lors d'une mise à niveau du plugin (car la réactivation automatique échoue). Je pense que ce même problème est responsable du fait que certains modules de mon tableau de bord ne se chargent pas parfois.

Compte tenu de la liste des plugins que j'ai installés , quelqu'un connaît-il des problèmes avec ou entre l'un d'entre eux qui pourraient causer ce problème?

Éditer:

Infos hébergement: DreamHost; Je pense que le serveur exécute une version Debian personnalisée avec Apache httpd

J'ai eu des problèmes toute la journée avec ce qui semblait être 404 ratés.

Quoi qu'il en soit, je viens de terminer de discuter avec une personne du support technique de dreamhost qui m'a dit qu'un compte d'utilisateur que j'avais avec lui atteignait les limites des ressources de la mémoire de processus (tous les processus) et que c'était ce qui causait d'étranges problèmes liés à htaccess. J'obtenais des erreurs 404 intermittentes à partir d'un fichier htaccess qui n'aurait pas dû être appelé du tout! c'était dreamhost avec un serveur de maison hantée.

apparemment, le robot de destruction de processus utilisé par dreamhost tuera un processus Web au milieu, puis pour une raison quelconque, l'apache (maintenant zombie) essaie en fait de terminer son travail (en faisant de son mieux pour sortir proprement de la fin peu glorieuse d'une sous-demande est ma meilleure estimation). il jette une erreur 500 dans le journal http principal, mais après cela, il déclenche réellement la condition et la règle de réécriture qui n'auraient jamais dû être déclenchées (en utilisant le fichier standard -f et le répertoire -d le fichier htaccess ci-dessus) - et il ne fonctionne pas 'écrivez pas une nouvelle entrée de journal! une nouvelle requête (homme invisible) déclenche alors le fichier d'index dans la dernière ligne du fichier htaccess

méfiez-vous des limites de ressources dans les comptes de base dreamhost! si vous dépassez leurs limites et que vous avez htacess avec des lignes mod_rewrite, vous verrez des choses étranges qui ne conviennent qu'à la nuit d'Halloween - des hommes invisibles, des 404 hantés! processus morts-vivants! zombie apache! htaccess se déplace tout seul! beurk!

j'espère que cela vous aidera à éviter quelques heures de douleur.

La seule façon de déboguer cela est de désactiver un plugin à la fois, en essayant à chaque fois de reproduire le problème avant de désactiver un autre plugin. Commencez avec les plugins qui ont quelque chose à voir avec l'administration de WP, puis descendez vers les plugins de thème, les widgets et autres.

Inspectez la page "Introuvable" qui vous est mieux servie (parcourez avec Opera et ouvrez le panneau Info qui vous montrera les en-têtes, parcourez alternativement avec Firefox et faites Firebug avec le panneau "Net" activé) et faites une recherche à travers tous vos plugins pour voir s'ils pourraient le servir directement. Sinon, consultez le journal du serveur Web pour savoir quelle ressource exacte il ne peut pas servir; un plugin peut faire une redirection ou une réécriture de fantaisie, ce n'est donc pas nécessairement l'URL que vous voyez dans votre navigateur qui cause le 404.

Je ne peux que raconter ma propre expérience, et jusqu'à présent, je n'ai pas trouvé de règle "définitive" pour résoudre tous les problèmes d'un seul coup.

Le problème majeur avec la configuration de DreamHost est que, dans l'éternel combat pour maintenir la consommation de mémoire au minimum, cela signifie se débarrasser d'autant de fonctionnalités que possible - à savoir, tout ce qui réduira la bande passante (bonne pour les visiteurs!) Ou CPU (bonne pour le serveur, mais DreamHost ne contrôle pas la consommation du processeur aussi agressivement qu'ils contrôlent la RAM). Par exemple, cela signifie se débarrasser de HTML + CSS gzip (qui consommera CPU + RAM) ou de l'un des nombreux plugins Minify (qui consommera également RAM). Plus le cache est sophistiqué (j'aime utiliser W3 Total Cache, ou au moins WP Super Cache), plus la RAM sera également consommée.

De même, de nombreux plugins qui limitent le nombre de requêtes MySQL pour améliorer les performances consomment à la place de la RAM. Il est donc difficile de trouver un compromis où vous pouvez toujours faire en sorte que votre site réponde avec de bonnes performances tout en évitant de consommer de la précieuse RAM!

Jusqu'à présent, mes meilleurs résultats sur les sites occupés sont de décocher l'optimisation de la vitesse de la page et la sécurité Web supplémentaire qui consommera apparemment beaucoup de RAM, et s'appuient plutôt sur une combinaison avec W3 Total Cache et Cloudflare (service de proxy inverse gratuit). Cloudflare fera effectivement la même chose que le module "Extra Web Security", mais comme il fonctionne en dehors de DreamHost, ça va. W3 Total Cache consomme beaucoup de mémoire, mais une fois que les pages sont stockées statiquement localement, Cloudflare les mettra en cache très efficacement - de sorte que vous pourriez obtenir 404/500 lors de la modification des publications, au moins vos visiteurs n'en feront pas l'expérience (Cloudflare peut également servir des pages statiques même si DreamHost donne un 404 ou un 500).

De plus, grâce à cet article , j'ai découvert que FastCGI utilise plus de RAM que CGI «normal». Et comme PHP 5.3 est meilleur dans la gestion de la RAM (collecte de déchets plus agressive, moins de fuites de mémoire), j'ai expérimentalement basculé vers PHP 5.3 CGI (pas FastCGI) sans optimisation de la vitesse de la page ni sécurité Web supplémentaire, en s'appuyant sur W3 Total Cache + Cloudflare pour accélérer le site. Maintenant, le backoffice est plus lent (plus de consommation CPU!) Mais au moins je ne vois pas 404/500 (jusqu'à présent!).

Je ne suis toujours pas satisfait de la combinaison, donc je continuerai certainement de modifier les paramètres de DreamHost dans l'espoir de réduire encore plus la consommation de RAM et d'obtenir des performances adéquates. Comme l'a dit @dgw, j'utilise également beaucoup de plugins - car j'ai besoin de leurs fonctionnalités. Tout le monde qui héberge WP avec DreamHost n'a pas de simples besoins en termes de blogs; plus le site est complexe, plus il nécessitera de fonctionnalités ... et c'est la beauté de WordPress, il vous suffit d'utiliser les plugins dont vous avez vraiment besoin, et de garder l'installation WP de base simple si vous êtes satisfait de quelques besoins. Les plugins, cependant, ne sont pas nécessairement "mauvais" ou lourds sur le site; mais c'est vrai que certains peuvent consommer beaucoup de RAM ...

C'est juste une idée approximative: si vous obtenez une "vraie" erreur 404 (avec des en-têtes définis), vous pouvez rechercher dans vos plugins et rechercher la fonction PHPheader() et le numéro 404. Cela pourrait réduire le nombre de plugins de 70 à quelques-uns. Il vous suffit ensuite de vérifier ces informations.

Cela peut être facilement fait avec un IDE comme Eclipse PDT qui offre la recherche d'un appel de fonction PHP spécifique.

À côté de cela, mais sans aucune garantie de succès, il s'agit d'écrire un plugin qui se connecte au paramètre d'en-tête, puis de vous donner la trace du code qui définit réellement un potentiel 404 (retour). Cela ne fonctionnerait que si le plugin utilise la fonction API WordPress. La première méthode pour rechercher la fonction PHP fonctionnera indépendamment de l'API WP.

Plus d'informations nécessaires:

1) Pourquoi tant de plugins?

2) Quel système d'exploitation est exécuté par votre hébergeur?

3) Quel serveur Web?

4) Avez-vous accès aux journaux du serveur httpd, en particulier aux journaux d'erreurs?

5) Que disent les journaux d'erreurs dans les délais entourant ces problèmes?

(Maintenant, à vrai dire, si nous généralisons pour que «J6P moyen exécutant WordPress puisse avoir cette question exacte, nous pourrions commencer par demander audit J6P de répondre au moins aux 5 questions ci-dessus ...)