Bascule de thème — Flexweg CMS

Basculer de thème change la façon dont chaque page de votre site public est rendue — templates différents, CSS différente, blocs différents, menus différents, possibles variantes d'images différentes. Le CMS gère la plupart de tout ça automatiquement, mais il vaut la peine de comprendre ce qu'il se passe pour récupérer des cas limites.

Ce que fait le clic « Activer »

Dans Thèmes → cliquez sur une carte de thème non actif → Activer :

1. Met à jour settings/site.activeThemeId dans le backend
   ↓
2. Les handlers de souscription se déclenchent — l'admin se re-rend
   ↓
3. Sync theme assets automatiquement :
   • Upload theme-assets/<nouveau-theme-id>.css
     (avec compileCss(config-sauvegardé) baké si disponible)
   • Upload theme-assets/<nouveau-theme-id>-menu.js (si présent)
   • Upload theme-assets/<nouveau-theme-id>-posts.js (si présent)
   ↓
4. Affiche un toast incitant à « Lancer Regenerate site → Toutes les pages HTML
   pour re-rendre chaque page avec le nouveau thème »

Notez : le clic Activer ne re-rend pas les pages publiées automatiquement. Tant que vous n'avez pas cliqué Regenerate, les pages publiques affichent encore le HTML rendu par l'ancien thème.

Pourquoi ce comportement ? Parce que vous voudrez peut-être :

Configurer la palette / les polices du nouveau thème AVANT de re-rendre
Désactiver des plugins qui ne sont compatibles qu'avec l'ancien thème
Pré-créer des pages utilisant les blocs du nouveau thème AVANT de re-rendre

Donc activer = changer le pointeur, mais le rendu attend.

La cascade automatique

À l'inverse, le clic Activer fait immédiatement quelques choses :

Theme assets sync : la nouvelle CSS est uploadée. Donc même les pages encore rendues par l'ancien thème ont accès à la nouvelle CSS (au cas où vous re-rendez dans la foulée).
/menu.json est ré-uploadé avec la résolution de menu pour le nouveau thème (au cas où le nouveau thème expose des items différents — rare).

La régénération

Après le clic Activer + le toast, cliquez Regenerate site → Toutes les pages HTML. Pour 100 posts, ça prend ~30 s ; pour 1000 posts, ~5 min. Chaque post est re-rendu avec le nouveau thème actif.

Pendant cette opération, les visiteurs du site public peuvent voir un mélange transitoire : les pages déjà re-rendues utilisent le nouveau thème, celles pas encore touchées utilisent encore l'ancien. C'est inévitable pour un site sans serveur applicatif — la cohérence est par fichier, pas globale.

Cas particulier : blocs de thème

Si vos posts utilisent des blocs spécifiques à l'ancien thème (ex. magazine/hero-split quand vous basculez vers corporate), ces blocs restent dans le markdown mais ne sont plus rendus. Le HTML public affiche des <div data-cms-block="magazine/hero-split" data-attrs="..."></div> vides.

Solutions :

Avant de basculer : éditez chaque post et remplacez les blocs spécifiques par des équivalents du nouveau thème
Après avoir basculé : faites pareil mais les pages publiques sont temporairement cassées entre-temps

Pour un changement de thème majeur, prévoir un script de migration des markers de bloc est souvent utile (voir le doc plugin si vous écrivez un thème qui veut accueillir le contenu d'un autre thème).

Cas particulier : variantes d'images

Chaque thème déclare dans son manifest les variantes d'images qu'il consomme (thumbnail 400×400, medium 800×800, etc.). Si le nouveau thème demande des dimensions que l'ancien ne produisait pas :

Les médias déjà uploadés n'ont pas ces variantes — le helper pickFormat retombe sur la plus grande disponible, ou sur admin-original (2000×2000 contain) comme dernier recours.
Les médias futurs sont uploadés avec le pipeline du nouveau thème, donc auront toutes les bonnes variantes.

Pour générer rétroactivement les variantes manquantes, il faut re-uploader les médias un à un, ou écrire un script qui itère et appelle processImage avec les nouveaux formats.

Cas particulier : `compileCss`

Si l'ancien thème avait des overrides de palette / polices configurées via sa page de réglages, ces overrides sont stockés dans settings.themeConfigs.<ancien-id> et persistent. Quand vous re-basculez plus tard vers cet ancien thème, ses overrides sont restaurés.

Le nouveau thème démarre avec son defaultConfig jusqu'à ce que vous le configuriez. Sa CSS uploadée à l'activation est manifest.cssText (la baseline) — pas encore d'overrides utilisateur. Quand vous sauvegardez sa page de réglages, compileCss(config) baking les overrides et re-upload la CSS.

Rollback

Si le nouveau thème ne convient pas, re-cliquez sur l'ancien dans la liste des Thèmes → Activer. La cascade fait l'inverse : sync de ses theme assets, et il faut Regenerate à nouveau pour repasser le HTML public à l'ancien rendu.

Aucune perte de données — les configs des deux thèmes restent en base, donc la bascule entre les deux est lossless.