Mise à jour : j’ai effectué le saut aujourd’hui. Deux erreurs dans ce qui précède
PostgreSQL. J’avais dit de vérifier que vous étiez en version 15 ou supérieure. Ce n’est pas le contrôle utile. L’image de base actuelle fournit PostgreSQL 18, et la reconstruction vous migre automatiquement : elle effectue un dump, restaure dans un nouveau cluster, puis s’arrête avec :
UPGRADE OF POSTGRES COMPLETE
To complete the upgrade, rebuild again using: ./launcher rebuild app
Votre site reste hors ligne jusqu’à ce que cette seconde reconstruction soit exécutée. Rien ne s’est mal passé, mais je ne m’attendais pas à une reconstruction en deux étapes. L’ancien cluster est conservé dans /shared/postgres_data_old, et vous devez disposer d’un espace libre égal à 2 fois la taille de votre base de données. Plus de détails dans Mise à jour PostgreSQL 18.
L’éditeur riche n’est pas inconditionnel. J’avais dit que c’était le cas. Le paramètre de site rich_editor a été supprimé, donc les administrateurs ne peuvent plus imposer un mode à l’échelle du site, mais il y a un basculement par utilisateur dans le composeur et Markdown est parfaitement intact.
Cloudflare peut bloquer l’enregistrement des thèmes. Il a fallu ajuster le CSS par la suite. Si un composant de thème contient un <script> dans son champ <head>, l’enregistrement renvoie un simple 403.
La règle gérée de Cloudflare XSS, HTML Injection – Script Tag bloque la requête PUT /admin/themes/<id>, car l’éditeur 2026.7 soumet tous les champs lors de l’enregistrement, et non seulement celui que vous avez modifié.
Une règle personnalisée le corrige (pas d’IP statique) :
starts_with(http.request.uri.path, "/admin/themes") and http.request.method eq "PUT"
Action : Ignorer → règles gérées.