Comment éliminer les erreurs bizarres 404 dans wp-admin?
Je lance 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 page /wp-admin/ qui apparaît de nulle part.
Réessayer simplement résout l'erreur, mais il est assez gênant si l'erreur se produit pendant la mise à niveau du plug-in (car la réactivation automatique échoue). Je pense que ce même problème est responsable de certains échecs de chargement de certains modules de mon tableau de bord.
Étant donné le liste des plugins que j'ai installés , est-ce que quelqu'un connaît des problèmes avec ou entre eux qui pourraient causer ce problème?
Modifier:
Informations d'hébergement: DreamHost; Je pense que le serveur exécute une version personnalisée de Debian avec Apache httpd
j'avais des problèmes toute la journée avec ce qui semblait être 404 ratés.
quoi qu'il en soit, je viens de terminer une conversation avec un membre du support technique de dreamhost qui m'a dit qu'un compte d'utilisateur que j'avais avec eux était en train de respecter les limites de ressources mémoire de processus (tous les processus) et que c'était ce qui causait d'étranges problèmes apparemment liés à htaccess. Je commençais à avoir des erreurs 404 intermittentes 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 tueur utilisé par dreamhost tue un processus Web au milieu, puis pour une raison quelconque, Apache (maintenant un zombie) tente effectivement de finir son travail (en faisant de son mieux pour se sortir proprement de la fin peu glorieuse d'une sous-demande est ma meilleure hypothèse). il jette une erreur 500 dans le journal http principal, mais après cela, il déclenche la condition de réécriture et la règle qui n'auraient jamais dû être déclenchées (à l'aide des fichiers standard -f et directory -d htaccess ci-dessus) - et cela ne écrivez pas une nouvelle entrée du journal! une nouvelle demande (homme invisible) déclenche ensuite 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 accès aux lignes mod_rewrite, vous verrez des choses étranges qui ne conviennent qu'à la nuit d'halloween - des hommes invisibles, hantés par des 404! processus morts-vivants! zombie Apache! htaccess se déplace tout seul! beurk!
espérons que cela vous aidera à éviter quelques heures de douleur.
Le seul moyen de résoudre ce problème consiste à désactiver un plug-in à la fois, en essayant à chaque fois de reproduire le problème avant de désactiver un autre plug-in. Commencez par les plugins qui ont quelque chose à voir avec l'administration de WP, puis descendez aux plugins de thème, widgets et autres.
Inspectez la page "Introuvable" pour indiquer que vous êtes mieux servi (naviguez avec Opera et ouvrez le panneau Informations qui vous montrera les en-têtes, ou naviguez avec Firefox et activez Firebug avec le panneau "Net" activé) et effectuez une recherche dans l'ensemble des éléments. vos plugins pour voir s’ils pourraient le servir directement. Si ce n'est pas le cas, consultez le journal du serveur Web pour connaître la ressource exacte qu'il est impossible de desservir. un plugin peut être en train de faire une redirection ou une réécriture sophistiquée, de sorte que ce n'est pas nécessairement l'URL que vous voyez dans votre navigateur qui est à l'origine du 404.
Je ne peux que raconter ma propre expérience et, jusqu'à présent, je n'ai pas trouvé de règle "définitive" permettant de résoudre les problèmes all d'un seul coup.
Le problème majeur de la configuration de DreamHost est que, dans le combat incessant visant à réduire au minimum la consommation de mémoire, vous devez supprimer autant de fonctionnalités que possible - à savoir, tout ce qui réduira la bande passante (ce qui est bon pour les visiteurs!) Ou le processeur (bien DreamHost ne contrôle pas la consommation du processeur de manière aussi agressive qu’ils contrôlent la mémoire vive). Par exemple, cela signifie que vous devez vous débarrasser de HTML + CSS (qui consommera plus de ressources CPU + RAM) ou de l’un des nombreux plug-in Minify (qui consomment également RAM). Plus le cache est sophistiqué (j'aime beaucoup utiliser W3 Total Cache ou au moins WP Super Cache), plus RAM sera également consommé.
De même, de nombreux plugins qui limitent le nombre de requêtes MySQL pour améliorer les performances consomment de la RAM. Il est donc difficile de trouver un compromis qui permette à votre site de rester performant tout en évitant de consommer précieux RAM!
Jusqu'à présent, mon meilleur résultat sur des sites très fréquentés est de décocher Optimisation de la vitesse de la page et Sécurité Web supplémentaire, qui consomment apparemment beaucoup de RAM, et de privilégier une combinaison de W3 Total Cache et de Cloudflare (service de proxy inverse gratuit). Cloudflare fera effectivement la même chose que le module "Sécurité Web supplémentaire", mais comme il fonctionne en dehors de DreamHost, tout va bien. W3 Total Cache consomme beaucoup de mémoire, mais une fois que les pages sont stockées statiquement localement, Cloudflare les cache très efficacement. Ainsi, vous pouvez obtenir 404/500 lors de l'édition de messages, au moins vos visiteurs ne les verront pas (Cloudflare peut également servir de 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 les CGI "normales". Et puisque PHP 5.3 est plus efficace pour gérer RAM (récupération de mémoire agressive, moins de fuites de mémoire), je suis passé de manière expérimentale à 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 de processeur!) Mais au moins, je ne vois pas 404/500 (jusqu'à présent!).
Je ne suis toujours pas satisfait de la combinaison, je vais donc certainement continuer à modifier les paramètres de Tweak DreamHost dans l'espoir de réduire encore plus la consommation de RAM tout en obtenant des performances suffisantes. Comme @dgw, j’utilise beaucoup de plugins, car j’ai besoin de leurs fonctionnalités. Tout le monde hébergeant WP avec DreamHost n'a pas simplement besoin de blogs; plus le site est complexe, plus il aura besoin de fonctionnalités ... et c'est ce qui fait toute la beauté de WordPress, il vous suffit d'utiliser les plugins dont vous avez réellement besoin et de garder la base WP installer simple si vous êtes heureux avec peu de besoins. Les plugins, cependant, ne sont pas nécessairement "mauvais" ou aussi lourds sur le site; mais il est vrai que certains peuvent consommer beaucoup de RAM ...
Ceci est juste une idée approximative: Si vous obtenez une "vraie" erreur 404 (avec les en-têtes définis), alors vous pouvez rechercher dans vos plugins et chercher la fonction PHP header() et le numéro 404 . Cela pourrait faire descendre le nombre de plugins de 70 à quelques-uns. Ensuite, il vous suffit de vérifier pour ceux-ci.
Cela peut être facilement fait avec un IDE comme Eclipse PDT qui offre la recherche d'un appel de fonction spécifique PHP.
À côté de cela, mais sans aucune garantie de son bon fonctionnement, consiste à écrire un plug-in qui s'accroche au paramètre d'en-tête, puis vous indique quel code définit réellement un potentiel 404 (backtrace). Cela ne fonctionnerait que si le plugin utilise la fonction API de WordPress. La première méthode à rechercher la fonction PHP fonctionnera indépendamment de l'API WP.
Plus d'informations nécessaires:
1) Pourquoi autant de plugins?
2) Quel système d'exploitation votre fournisseur d'hébergement utilise-t-il?
3) Quel serveur web?
4) Avez-vous accès aux journaux du serveur httpd, en particulier les journaux des 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 "un J6P moyen utilisant WordPress pourrait avoir cette question exacte, nous pourrions commencer par demander à J6P de répondre au moins aux 5 questions ci-dessus ...)