Quand un nom de dossier a sauvé mon site WordPress — et comment j’ai évité 10 heures de galère sans écrire une ligne de code

sphinx article 00448

La première fois que j’ai lancé le site WordPress de Victoria, j’ai cru que l’ordinateur s’était mis à rire. Le menu principal affichait une liste de trois points, comme un emoji perdu entre des parenthèses. J’ai cliqué, réessayé, rafraîchi, et finalement, j’ai zoomé sur le panneau de gestion. C’est là que j’ai vu le nom du dossier : portfolio-2024. Rien de choquant, sauf que le tiret ressemblait à une barre d’espace. Et là, ça a cliqué.

Si tu as déjà testé un site en direct et que tu as ressenti cette panique quand les éléments se mettent à disparaître, tu connais l’adrénaline. Comment un détail aussi invisible a-t-il tout faussé? Et surtout, comment le réparer sans toucher au code?

Le piège du tiret devenu espace

Le problème, c’est que WordPress, comme plein de serveurs, a une manière bien à lui de traiter les noms de dossiers. Lorsque j’ai importé les fichiers de Victoria via FTP, le dossier portfolio-2024 a été interprété comme portfolio 2024. Pas grave? Si ton serveur utilise Apache et que les modules de gestion des URI sont activés, ce genre de détail peut foutre en l’air les chemins d’accès.

Lorsque j’ai vérifié les logs avec l’outil Debug Bar de WordPress, j’ai vu que le menu pointait vers /portfolio-2024/, mais le serveur cherchait /portfolio%202024/. Et là, bingo : le serveur a arrêté de servir le contenu.

3 secondes, 1 clic : Comment j’ai réparé sans code

Le fix, c’est d’avoir renommé le dossier directement via le gestionnaire de fichiers de WordPress. J’ai cliqué sur le dossier, modifié le nom en supprimant l’espace, et hop — le menu s’est reconnecté en moins de temps qu’il n’en faut pour dire « serveur ».

Pourquoi ça a marché? Parce que WordPress ne rechargera pas les menus tant qu’il ne voit pas un changement dans la structure. Le renommage force un rechargement des chemins, et le serveur retrouve la bonne URL. Pas besoin de toucher aux templates ni aux classes CSS.

Le message du serveur : Lire les logs, mais pas trop

Ce genre de problème, c’est un rappel : les logs ne sont pas des devinettes. Je me souviens que Victoria m’avait dit que ses images ne s’affichaient pas sur mobile. Je suis allée voir les erreurs 404 dans Access Log et là, j’ai vu que les noms de fichiers avaient des espaces mal encodés.

Le truc, c’est de ne pas paniquer et de se fier aux outils existants. Si tu as accès à un gestionnaire de fichiers ou à FTP, tu peux corriger ça sans demander à un développeur. Et si tu n’es pas en mesure de le faire directement? Utilise un plug-in comme Better Search Replace pour corriger les chemins dans la base de données. Mais attention : fais une sauvegarde avant.

Et si ton site devient un labyrinthe?

Le paramètre de log Linux qui a sauvé mon site WordPress en 3 secondes

Cet article raconte comment un autre détail — un paramètre de log — a transformé une panne en solution. Ce n’est pas un hasard si les bugs invisibles sont les plus redoutables. Ils ne font pas de bruit, mais ils sabotent tout.

Alors, tu as déjà eu un site WordPress qui se met à planter pour un détail invisible? Un tiret, une virgule, une minuscule mal placée? J’aimerais savoir si tu as réussi à t’en sortir sans appel à un pro — et si oui, comment.

— Élise Morane, étudiante en informatique et passionnée d’IA — Point Hub

Laisser un commentaire

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *