La première fois que j’ai vu la page blanche de mon site WordPress, j’ai cru à une erreur de mon code. J’ai refait le déploiement trois fois, vérifié les logs, rebranché l’interrupteur du routeur… et rien. Jusqu’à ce que je tombe sur une ligne de configuration Apache qui ressemblait à un code secret de mission impossible.
L’histoire est simple : un serveur Ubuntu, un site WordPress en local, et un.htaccess qui ne fonctionnait pas. Mais derrière cette simplicité, une cascade d’erreurs qui m’a coûté une journée complète de galères.
Le piège du « mod_rewrite » désactivé
Le premier signe suspect? Le site ne répondait qu’en http, pas en https, et les redirections vers la page d’authentification WordPress ne fonctionnaient pas. J’avais suivi un tutoriel pour activer le module `mod_rewrite` en tapant `sudo a2enmod rewrite`, mais je n’avais pas relu les logs d’Apache.
Là, j’ai découvert un message en clair : `The requested URL was not found on this server`. Un détail m’a sauté aux yeux : le fichier `.htaccess` était présent, mais les règles de réécriture n’étaient pas appliquées. J’ai alors vérifié le fichier de configuration d’Apache et vu qu’un `AllowOverride None` bloquait l’interprétation des règles WordPress.
C’est là que j’ai réalisé que 90 % des problèmes de déploiement WordPress viennent de configurations Apache mal ajustées. Le module `mod_rewrite` est l’équivalent d’un interrupteur : s’il est éteint, les URLs personnalisées et les redirections deviennent des fantômes.
Les trois coups de marteau
Pour corriger, j’ai dû :
Activer `mod_rewrite` via `sudo a2enmod rewrite` et redémarrer Apache.
Modifier le bloc `` dans le fichier de configuration Apache pour remplacer `AllowOverride None` par `AllowOverride All`.
Relancer la génération du `.htaccess` via l’interface WordPress.
Là, l’erreur de syntaxe est arrivée : j’avais oublié de supprimer une balise `
Comment une collègue m’a sauvé les fesses
À un moment, j’ai envoyé les logs à une collègue via Discord. Elle a trouvé une trace d’erreur étrange : `AH00114: No passing Referer: server busy`. Je n’étais pas en mesure de la comprendre, mais ça m’a fait prendre conscience que je n’avais pas testé les règles de sécurité d’Apache.
En fait, la configuration par défaut d’Apache bloque souvent les accès non autorisés. Pour déboguer, j’ai ajouté temporairement `Require all granted` dans le fichier de configuration, ce qui a libéré le passage. Mais attention : c’est un patch temporaire, pas une solution à long terme.
Le calme après la tempête : une leçon de patience
Aujourd’hui, le site fonctionne. Mais je me demande si je n’aurais pas évité cette journée perdue en lisant une documentation plus claire. Si tu passes par la même galère, voici mon conseil :
– Vérifie les logs d’Apache dès le début.
– Active `mod_rewrite` et vérifie les balises `
– Teste avec un fichier `.htaccess` minimal avant de tout reconfigurer.
Et si tu veux en apprendre plus sur les erreurs courantes de WordPress, cet article pourrait t’épargner des heures de debug.
L’erreur oubliée, le site sauvé
Quand tu passes des heures à chercher une erreur qui se résout en quelques lignes de code, tu comprends que l’informatique, c’est aussi une question de patience. Mais parfois, c’est un paramètre Apache qui te rappelle que tout n’est pas programmé dans le code… c’est aussi dans la configuration.
Alors, toi, as-tu déjà perdu des heures pour une virgule mal placée? Ou pire, un module oublié?
— Élise Morane, étudiante en informatique et passionnée d’IA — Point Hub