Au risque de perdre les moins geeks de mes (nombreux) lecteurs, ouvrons un peu le capot du blog… Pour les curieux, je mets les liens vers de la doc (le plus souvent en anglais, faut savoir ce qu’on veut ; et comme on dit : RTFM !)
Je ne sais pas si tu as remarqué, mais il y a eu une amélioration considérable de ce blog… Regarde ta barre d’adresse. Jusqu’à ce matin, les URL (les liens, quoi) étaient un peu momoches : du genre https://www.alchimie-web.com/?p=304.
Ce ?p=304 ça veut juste dire qu’on veut lire l’article numéro 304. On demande à WordPress de nous afficher l’article 304. Ça parle à WordPress et à la base de données, mais pas beaucoup au lecteur. Et pas non plus aux moteurs de recherche qui, du coup, ne savent pas les sujets passionnants abordés dans ces pages !
(Par principe, je n’ai pas fait du tout de SEO, privilégiant la qualité du lectorat.)
Mais depuis ce matin, les URL sont devenues parlantes, plus sexy, et plus pro ! Elles ressemblent désormais à ça : https://www.alchimie-web.com/2022/02/08/les-slides-qui-ont-fait-glisser-bojo/ – l’URL contient des méta-données, à savoir la date de publication et le titre de l’article, ce qui la rend tout de suite beaucoup plus attractive… Enfin, à tout le moins, signifiante.
Et tout ça grâce à un tout petit réglage que je n’imaginais pas aussi simple (c’est d’ailleurs pour ça que je ne m’y étais pas collé avant !)
Architecture
Un petit mot sur l’architecture du blog, dont je suis assez fier, et qui m’a demandé pas mal de temps pour mettre tout ça debout, d’où ma tentative de vulgarisation.
WordPress (le gestionnaire de contenus, le moteur du site) tourne dans un container Docker (un fabuleux outil de para-virtualisation)
nginx traite les requêtes web, en mode reverse-proxy : quand une requête arrive sur le serveur pour le domaine www.alchimie-web.com, elle est redirigée vers WordPress (dans son container Docker, vers un worker php-fpm pour être précis)
Voici la partie intéressante du fichier de configuration (en orange, les lignes ajoutées ce matin pour obtenir de jolies URL…) :
location / {
try_files $uri $uri/ /index.php?q=$uri&$args;
}
location ~ \.php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
fastcgi_pass atanor:9000;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
}
Quelques explications :
location / {
try_files $uri $uri/ /index.php?q=$uri&$args;
}C’est là que tout se joue : on indique à nginx ce qu’il doit faire avec toutes les requêtes (location /) qui arrivent sur le domaine configuré par cette section server. En l’occurrence, il invoque index.php avec deux paramètres : l’url originale ($uri) et la query_string originale ($args).
Comme on invoque un fichier php (index.php), la nouvelle requête est passée au filtre suivant (location ~ \.php) qui la fait passer au backend (fastcgi_pass atanor:9000), c’est-à-dire au worker php-fpm dans le container Docker où réside WordPress.
location ~ \.php$ {
try_files $uri =404;
(...)
}Cette ligne aurait dû être là depuis longtemps : c’est elle qui va renvoyer un code HTTP 404 (page non trouvée) si on (généralement un utilisateur malveillant) essaie d’accéder à un script php autre que index.php.
Et après…
Ben après, y’a plus qu’à ajuster la configuration de WordPress, dans le menu Réglages > Permaliens et de choisir le format des liens.
Alors, bien sûr, il n’y a rien là de très sorcier pour les gourous de nginx, mais comme c’est pas toujours très bien documenté (euphémisme…), ce petit topo peut rendre service.