Mise à jour : j’ai effectué la migration aujourd’hui. Deux points que j’ai mal expliqués plus haut
PostgreSQL. J’avais indiqué de vérifier que vous étiez en version 15 ou supérieure. Ce n’est pas la vérification utile. L’image de base actuelle est livrée avec PostgreSQL 18, et la reconstruction effectue la migration automatiquement : elle effectue un dump, restaure les données dans un nouveau cluster, puis s’arrête avec le message suivant :
UPGRADE OF POSTGRES COMPLETE
To complete the upgrade, rebuild again using: ./launcher rebuild app
Votre site reste hors ligne jusqu’à ce que la 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 aurez besoin d’une espace libre égale à 2 fois la taille de votre base de données. Plus de détails dans PostgreSQL 18 update.
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é, de sorte que les administrateurs ne peuvent plus forcer un mode à l’échelle du site, mais il existe une bascule par utilisateur dans le composeur et le 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 au lieu de n’envoyer que celui que vous avez modifié.
Une règle personnalisée résout le problème :
starts_with(http.request.uri.path, "/admin/themes") and http.request.method eq "PUT"
Action : Ignorer → règles gérées.