WordPress en-dehors de WordPress et les erreurs 404

Côté technique

WordPress, c’est pas mal du tout.
Mais des fois, on se doit de le faire cohabiter avec d’autres sites, que ce soit avec des pages écrites à la main ou bien d’autres plateformes web.

Pour pouvoir utiliser les fonctions WordPress en-dehors de WordPress, dans un autre script PHP, il est généralement conseillé d’y intégrer le script wp-blog-header.php. Et ça marche. Du moins, en apparence. En fait, selon le programme avec lequel on va accéder à cette page, le comportement va varier. En analysant les logs du serveur (prenons ici Apache), on se rend vite compte que si cette page est bien envoyée en réponse, le code HTTP associé est en fait un code 404 (page introuvable).

127.0.0.1 – – [19/Apr/2011:00:31:31 +0200] « GET /galerie/ HTTP/1.1 » 404 29682

Cela pose un problème car certains programmes risquent de s’arrêter à l’analyse de ce code.

Pourquoi ce comportement ? Et bien parce que le script wp-blog-header.php analyse la requête et détermine si un billet ou une page correspond à cette requête. S’il n’y a rien, il envoie un header 404. A la suite de quoi, le reste de la page PHP est traité. Si par chance, la page a déjà envoyé des headers avant d’intégrer ce script WordPress, cette situation aura été évitée. Mais elle aboutira peut-être à un message indiquant que les entêtes HTTP ont déjà été envoyés.

La solution pour éviter ce problème, c’est de bannir wp-blog-header.php et d’inclure à la place le script wp-load.php.
Et là, ça marche pour de bon.

127.0.0.1 – – [19/Apr/2011:00:33:56 +0200] « GET /galerie/ HTTP/1.1 » 200 29682

Et pour la petite histoire…

J’ai découvert ce problème suite à plusieurs étrangetés sur mon site :

  • Les outils de Google pour les webmasters m’avaient indiqué à plusieurs reprises des erreurs 404 dans l’exploration de mon site, alors même que ces pages s’affichaient très bien dans Firefox.
  • En fait, le déclic a été un script PHP que j’invoquais depuis un programme Java. Celui-ci ne s’exécutait pas du tout.
  • Partant de ça, j’avais pu vérifier que ce script ne s’exécutait que dans Firefox. Mais pas dans Google Chrome, ni dans Internet Explorer 8.
  • Enfin, le validateur du W3C m’a signalé la même chose (erreur 404). Au final, les logs Apache ont confirmé l’évidence.

Et c’est donc bien Firefox qui a été un peu trop cool dans cette affaire.
J’ai passé 3 heures à éliminer des explications (réécriture d’URL bancale, mauvaise inclusion dans les scripts PHP, script foireux…) avant de n’avoir plus qu’une seule explication encore cohérente. Et je vous ai mis la solution plus haut…

Publicités

About this entry