#Publier
Un thème installé, importé, dupliqué ou poussé arrive toujours en brouillon. Il faut un second geste pour qu’il remplace celui que voient les visiteurs. Ce guide dit ce que ce geste change exactement, ce qui se passe pour quelqu’un qui charge la page pendant, comment revenir en arrière, et pourquoi le thème publié refuse d’être supprimé.
#Brouillon et publié
Un site a au plus un thème publié — la base le garantit par un index partiel, ce n’est pas une convention. Tous les autres sont des brouillons, en nombre libre.
| Brouillon | Publié | |
|---|---|---|
| Visible par les visiteurs | non | oui |
| Prévisualisable | non, nulle part | c’est le site |
| Modifiable au CLI | oui | oui, mais suivre prévient |
| Supprimable | oui | non — 409 theme_publie |
| Combien par site | autant qu’on veut | un seul |
La deuxième ligne est celle qui coûte du temps à tout le monde. Il n’existe
aucun aperçu d’un thème brouillon : le rendu public lit le thème de rôle
publie et lui seul, et « Voir le site » ouvre toujours l’adresse publique.
Publier n’est donc pas seulement la dernière étape, c’est aussi la seule façon
de regarder. Voir La boucle locale pour organiser le
travail autour de cette contrainte.
#Ce que publier change réellement
Trois écritures, dans cet ordre, et rien d’autre.
L’ancien thème est démis
Tous les thèmes du site dont le rôle vaut
publierepassent enbrouillon. L’ordre compte et il est contraint : il faut démettre avant de promouvoir, sinon deux thèmes publiés coexistent le temps d’une instruction et l’index de la base refuse la seconde écriture.Le nouveau est promu
Son rôle passe à
publieet sonmaj_leest mis à l’heure. Ses fichiers ne bougent pas — ils étaient déjà en base depuis lepousser, l’installation ou l’import. Publier ne déplace aucun octet.Une page d’accueil est garantie
Si le site n’a pas de page marquée comme accueil, elle est créée. Publier un thème, c’est mettre un site en ligne ; sans page d’accueil, l’écran « Pages » reste vide et le référencement n’a nulle part où poser un titre.
Cette création est sans conséquence sur la publication : elle a lieu après, et si elle échoue, le thème reste bien en ligne. Une page qui ne se crée pas ne doit pas faire échouer un thème qui, lui, fonctionne.
Ce que publier ne change pas, et qui surprend :
- Ni le contenu, ni les pages, ni le menu, ni les articles. Ils n’appartiennent pas au thème. Changer de thème change l’habillage, pas ce qu’il y a dedans.
- Ni les réglages de l’ancien thème. Ils vivent dans le
config/settings_data.jsonde ce thème-là et l’attendent s’il revient. - Aucun fichier. Un brouillon publié puis démis retrouve exactement l’état dans lequel il était.
#Ce que voit un visiteur pendant
Rien de particulier, et c’est voulu.
Les pages publiques sont rendues à chaque requête — pas de cache à purger, pas de régénération à attendre. Une requête arrivée avant la mise à jour rend l’ancien thème et se termine normalement ; la suivante rend le nouveau. Il n’y a pas d’état intermédiaire dans lequel le site serait vide ou cassé : le basculement est un changement de ligne en base, et les deux thèmes sont complets de part et d’autre.
Concrètement : quelqu’un qui lit une page ne voit rien ; il verra le nouveau thème au clic suivant.
Le seul scénario où un visiteur voit quelque chose de bizarre est celui d’une
page mise en cache par son navigateur, avec une feuille de style qui, elle,
a changé d’adresse — l’adresse d’un asset contient l’identifiant du thème
(/theme-assets/<id>/theme.css), donc changer de thème change l’adresse. Un
rechargement forcé règle le cas.
#Publier
Site web → dans Brouillons, le bouton Publier de la ligne voulue.
Une confirmation apparaît : « Tes visiteurs verront ce thème immédiatement, à la place de celui qui est en ligne. Tu pourras remettre l’ancien quand tu veux. »
Ce que tu dois voir ensuite : la ligne quitte la liste des brouillons et remonte en haut de l’écran avec la pastille En ligne, l’ancien thème descend dans les brouillons, et l’aperçu se recharge.
node scripts/theme.mjs publier --theme=22222222 Publier, c'est changer ce que voient les visiteurs du site.
en ligne aujourd'hui : Forge
remplacé par : Forge v2 22222222
Confirmer la publication ? [o/N]La confirmation nomme les deux thèmes, l’actuel et le remplaçant. C’est le
seul moment où une erreur de --theme= se rattrape, et c’est pour cela que la
question ne se réduit pas à « Confirmer ? ».
Si le thème visé est déjà publié, la commande le dit et ne fait rien :
« Forge » est déjà le thème publié.publier demande toujours confirmation, y compris en intégration continue —
il n’a pas de --force. C’est volontaire : pousser des fichiers est réversible,
publier est vu.
curl -X PATCH https://cms.webcosa.com/api/themes \
-H "Authorization: Bearer wc_…" \
-H "X-Webcosa-Site-Cible: mon-client" \
-H "content-type: application/json" \
-d '{"id":"22222222-2222-4222-8222-222222222222","publier":true}'Portée themes obligatoire. Voir Thèmes.
#Revenir en arrière
Publier l’ancien. Il n’y a pas d’autre mécanisme, et il n’en faut pas d’autre : l’ancien thème est redevenu un brouillon au moment où le nouveau a été promu, avec tous ses fichiers et tous ses réglages intacts.
Retrouver l’ancien
node scripts/theme.mjs listerid nom version rôle modifié 22222222 Forge v2 1.0.0 publié il y a 2 min 11111111 Forge 1.0.0 brouillon il y a 4 jLe republier
node scripts/theme.mjs publier --theme=11111111Ou, dans le CMS, le bouton Publier de sa ligne dans les brouillons.
Vérifier
Recharge l’adresse publique. Le retour est immédiat, pour la même raison que l’aller : pas de cache à purger.
Renomme tes thèmes. « Forge (copie) », « Forge (copie) (copie) » ne dit rien trois semaines plus tard, et c’est cette ligne-là qu’il faudra retrouver en urgence. « Forge — avant refonte janvier » se lit tout seul. Le nom n’apparaît que dans ton espace, jamais sur le site : Site web → menu à trois points → Renommer.
#Pourquoi le thème publié ne se supprime pas
{
"error": "theme_publie",
"message": "Ce thème est celui que voient tes visiteurs. Publie-en un autre avant de le retirer."
}409, et c’est délibéré. Supprimer le thème publié éteindrait l’apparence du
site en un clic, sans rien pour la remplacer — et il n’y a pas de corbeille : le
code et les modifications partiraient définitivement. La garde force le geste
qu’on voudrait de toute façon, dans l’ordre où on le voudrait : publier
l’autre d’abord, retirer ensuite.
Deux gardes voisines relèvent de la même logique :
Les fichiers indispensables409 fichier_requislayout/theme.liquid, templates/index.json et config/settings_schema.json
ne se suppriment pas, même dans un brouillon. Sans coquille ni template, le
thème ne rend plus rien.
Le repli du rendusilencieuxSi un thème publié perd malgré tout sa coquille, le rendu rend la main au lieu de servir une page vide : le site repart sur l’ancien moteur et reste debout. Un thème à moitié écrit ne doit pas éteindre un site — mais tu verras alors l’apparence d’avant, pas ton thème, et c’est la première chose à soupçonner devant un site qui « a perdu son thème ».
#Retirer un brouillon
Une fois qu’un autre thème est en ligne, le retrait ne demande rien de particulier. Site web → menu à trois points → Retirer le thème, avec la confirmation qui va bien : « Tout le code de ce thème sera effacé, y compris tes modifications. Télécharge-le d’abord si tu veux pouvoir y revenir. »
Prends l’avertissement au sérieux : Télécharger exporte le thème entier en un fichier JSON, réimportable tel quel. C’est la seule sauvegarde qui existe.
Un site dont l’essai est terminé peut encore retirer un brouillon — c’est la
seule écriture de thème qui reste permise, parce qu’elle ne change rien à ce que
voient les visiteurs. Publier, pousser et importer, eux, répondent 402.

