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

8

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

dgw
la source
1
Ne pas être un PITA mais c'est vraiment un problème de support et pas quelque chose que nous aborderions ici; Je vais voter pour clore. Demandez plutôt à http://wordpress.org/support . Si vous effectuez des tests et affinez votre question pour qu'elle s'applique à plus que votre situation, cela pourrait faire une question acceptable ici. Encore une fois, désolé d'être de cette façon, mais nous, les réponses WordPress devraient être applicables à tous les utilisateurs et des tonnes de demandes d'assistance tueront cela.
MikeSchinkel
Je suis d'accord donc je vais voter pour clore aussi.
Ben Everard
1
D'accord. Voter pour fermer car trop localisé.
John P Bloch
2
Je vote pour ne pas fermer. Beaucoup de nouveaux utilisateurs de WP peuvent rencontrer des erreurs 404 dans WP-Admin, et finalement cela revient à un bug dans un plugin ou un thème, ou leur effet peut-être sur une règle de réécriture (soit stocké dans la base de données dans wp-options ou dans le. fichier htaccess). Ce que nous devrions faire, à la place, est de fournir des étapes de dépannage générales que l'on peut prendre pour identifier la zone à problème beaucoup plus rapidement.
Volomike
Eh bien, même cela a tendance à être une question d'assistance, il contient suffisamment d'informations pour au moins suggérer des moyens de résoudre rapidement le problème.
hakre

Réponses:

6

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 source
J'ai certainement beaucoup de mod_rewritechoses dans mes .htaccessfichiers. On dirait que c'est ce qui m'arrive. Je savais que j'avais atteint des limites de mémoire avec mes travaux de sauvegarde, mais pas pour les «vraies» demandes. Merci d'avoir partagé votre expérience; j'espère que votre réponse fera gagner beaucoup de temps aux gens.
dgw
Ce n'est pas seulement Dreamhost. J'ai déménagé de Dreamhost vers un serveur privé ailleurs, et j'ai toujours ce problème.
super vrai
4

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.

Asbjørn Ulsberg
la source
Avec 70 plugins, ce serait vraiment bien si on pouvait trouver un moyen de le faire très rapidement sans avoir à désactiver et à tester manuellement chacun d'eux, comme avec un fichier de testeur de plugin.
Volomike
Je vois que vous avez modifié votre réponse d'origine avec un excellent conseil pour trouver la réponse plus rapidement.
Volomike du
Merci, asbjornu. J'envisagerai de le faire après mon retour de vacances avec ma famille.
dgw
J'ai parcouru les journaux du serveur et je n'ai rien trouvé de plus spécifique que "Fin prématurée de l'en-tête de script".
Je
3

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 ...

Gwyneth Llewelyn
la source
3

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.

hakre
la source
Cela semble prometteur. Quelque chose d'autre à examiner après mes vacances. :)
dgw
J'ai réussi à faire quelques recherches alors que j'étais encore en dehors de la ville, et j'ai seulement constaté que mon plugin de sauvegarde semblait appeler à la sortie d'un 404. Firebug montre que c'est vraiment un 404, cependant. Quelques progrès ... Cependant, j'ai maintenant du mal à déclencher le problème, donc je suppose que je vais faire une pause. Je déteste les bugs intermittents!
dgw
2

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 ...)

ZaMoose
la source
J'ai tous ces plugins parce que j'utilise les fonctions qu'ils servent; pourquoi d'autre? Les journaux d'erreurs ne disent pas grand-chose. Je suis sur DreamHost, donc je pense que le serveur exécute une construction Debian personnalisée avec Apache httpd.
dgw
Maintenant que vous le mentionnez, je vois aussi ces erreurs aléatoires sur mes sites DH. Cela se produit en particulier lorsque j'essaie de faire une mise à niveau réseau dans mes installations MS et d'exécuter l'importateur. Étrange.
ZaMoose