Concepts fondamentaux

WebBlocks CMS utilise un modèle de contenu relationnel explicite construit autour des pages, des layouts, des slots et des blocs.

La structure de base est la suivante :

Page -> Layout -> Slots -> Blocks

• Une page possède le routage, le contexte de site, l'état du flux de travail et le choix du layout.
• Une page peut également posséder des lignes relationnelles de Page Assets référençant des fichiers CSS et JS à portée de page.
• Un layout définit les régions structurelles disponibles.
• Les slots sont des zones de placement nommées à l'intérieur du layout, telles que header, main, sidebar et footer.
• Les blocs sont les véritables unités de contenu placées dans les slots et, lorsque cela est pris en charge, imbriquées sous d'autres blocs.

Les pages ne stockent pas de JSON libre de type page builder. Le contenu et les relations sont conservés dans des tables relationnelles afin que la structure reste explicite et vérifiable.

• Page Assets est une fonctionnalité core du CMS destinée aux références de fichiers CSS et JS à portée de page.
• Page Assets est stocké de manière relationnelle dans page_assets, et non à l'intérieur du JSON de pages.settings.
• La V1 n'accepte que des chemins locaux de l'installation sous /site/....
• Les URL externes, le CSS en ligne, le JS en ligne, les chaînes de requête, les fragments, la traversée de répertoires et les extensions non conformes sont rejetés.
• Actuellement, le CSS n'est rendu que dans le head du document public.
• Actuellement, le JS n'est rendu que dans le head du document public avec defer.
• Les fichiers publics appartenant au CMS se trouvent sous public/cms/.
• public/storage est le lien symbolique de stockage public de Laravel vers storage/app/public ; il est distinct des fichiers de surcharge de site ou de page.
• Les chemins publics canoniques des fichiers sont public/site/{site_handle}/css/site.css, public/site/{site_handle}/js/site.js, public/site/{site_handle}/pages/{page_slug}/page.css et public/site/{site_handle}/pages/{page_slug}/page.js.
• Page Assets n'est rendu que pour la page publique propriétaire et est exclu des layouts d'administration et des pages non concernées.
• Les révisions de page, la duplication, le déplacement et l'export ou l'import de site traitent Page Assets comme une configuration appartenant à la page.
• L'import JSON d'une seule page peut également créer des lignes page_assets lorsque la charge utile utilise des chemins locaux /site/... valides qui satisfont les règles de validation existantes des Page Assets.
• L'indexation de la recherche ne traite pas les chemins des Page Assets comme du contenu du corps de la page.

• Une page appartient à exactement un site à la fois.
• Le formulaire habituel Edit Page conserve Site en lecture seule pour les pages existantes.
• Dupliquer une page crée un nouvel enregistrement de page dans le même site ou dans un autre site accessible.
• Les déplacements de pages entre sites utilisent un flux de travail dédié Move to another site plutôt qu'une modification de champ en ligne.
• La duplication de page utilise un flux de travail dédié Duplicate page plutôt que de s'appuyer sur le formulaire de page habituel.
• Le déplacement s'exécute comme une transaction contrôlée afin que pages.site_id et page_translations.site_id restent valides au regard de la clé étrangère composite (page_id, site_id).
• La duplication démarre toujours la nouvelle page en brouillon et copie l'état du contenu sans copier l'historique des révisions de la page source.
• Le déplacement préserve l'id de la page, les traductions, les slots, les blocs appartenant à la page, les traductions des blocs, l'ordre, l'état du flux de travail et l'historique des révisions.
• La duplication préserve le layout, les traductions, les slots, les blocs appartenant à la page, les relations de blocs imbriqués, les traductions des blocs et les références compatibles aux Shared Slots, mais elle crée un nouvel id de page.
• Les conflits de chemin sur le site cible sont des erreurs de validation bloquantes dans la version actuelle.
• Les références aux Shared Slots doivent pouvoir être remappées vers des Shared Slots compatibles de même handle sur le site cible, faute de quoi le déplacement est bloqué.
• La duplication au sein du même site préserve les références existantes aux Shared Slots.
• La duplication entre sites ne remappe que les Shared Slots compatibles de même handle du site cible.
• Lorsqu'une duplication entre sites ne peut pas remapper certains slots adossés à des Shared Slots, le comportement par défaut reste le blocage de la duplication.
• Le flux de travail de duplication peut désormais désactiver explicitement uniquement ces slots incompatibles de la page dupliquée au lieu de conserver une référence de Shared Slot inter-sites invalide.
• Ce repli optionnel écrit le slot de la page dupliquée comme disabled, efface shared_slot_id, laisse la page source inchangée et ne copie pas les arbres de blocs des Shared Slots dans la page dupliquée dans cette version.
• Les outils de portabilité au niveau du site, tels que Export / Import et Site Clone, restent distincts des déplacements et de la duplication de pages.
• Admin -> Pages -> Import Page est un flux de travail de portabilité à portée de page. Il crée une nouvelle page à partir d'une charge utile JSON documentée webblocks.cms.page.v1 et reste volontairement distinct de l'Export / Import au niveau du site.
• L'import V1 d'une seule page crée toujours une nouvelle page et l'importe toujours en brouillon.
• L'import V1 d'une seule page n'importe pas l'historique des révisions de la page source.
• Dans l'import d'une seule page, les slots de page adossés à des Shared Slots doivent référencer un Shared Slot compatible du site cible via un handle stable. En V1, l'importateur ne crée pas de Shared Slots automatiquement.

• L'identité produit de WebBlocks CMS est fixe dans le shell d'administration et provient de App\Support\WebBlocks.
• Project Identity est le contexte d'administration au niveau de l'installation, configuré dans Admin -> System -> Settings.
• Project Identity comprend actuellement Project Name et Project Tagline.
• Project Identity ne sert qu'au contexte de la barre supérieure d'administration et aux titres du navigateur dans l'administration.
• Project Identity ne modifie pas la marque fixe de la barre latérale WebBlocks CMS, le pied de version de la barre latérale, les métadonnées publiques du site, la favicon publique, la portée de la recherche publique ni les valeurs SEO des traductions de page.
• Les enregistrements de site possèdent l'identité et les métadonnées destinées au public.
• sites.name reste le nom interne de l'enregistrement dans l'administration.
• display_name est la surcharge facultative du nom public du site.
• tagline est un texte public facultatif pour le site.
• seo_title, seo_description et seo_keywords sont des métadonnées de repli au niveau du site.
• favicon_media_id et social_image_media_id sont des références média facultatives au niveau du site pour la sortie du head public.
• site_variables sont des valeurs en texte brut réutilisables et facultatives au niveau du site, destinées au remplacement contrôlé de jetons publics.
• Les lignes de traduction de page possèdent également des champs de surcharge SEO localisés tels que seo_title, seo_description, seo_keywords, og_title, og_description et og_image_media_id.
• Cela garde les métadonnées publiques de la page dépendantes de la langue et hors des réglages JSON partagés de la page.

• Media est le nom canonique des fichiers téléversés partagés dans tout le runtime actif du CMS.
• Les noms techniques actifs utilisent désormais Media, media_id, media, media_folders et block_media dans le code de runtime actuel, les requêtes, les révisions et les paquets de transfert de site.
• Les anciens noms Asset ne subsistent que pour les wrappers de compatibilité, les migrations historiques et la normalisation d'anciennes charges utiles ou archives.
• Admin -> Media conserve le titre principal de la liste Media et le titre de carte du listage Media Library.
• Dans la liste Media, le lien du titre et l'icône crayon ouvrent tous deux Edit Media: {title} et transportent une URL de retour sûre vers la liste filtrée en cours.
• L'icône en forme d'œil reste l'action d'aperçu agrandi en fenêtre modale depuis la liste.
• La route de détail /webadmin/media/{id} redirige vers /webadmin/media/{id}/edit, afin que les liens de détail des médias mènent à l'écran d'édition canonique.
• Edit Media réunit l'aperçu, les détails du fichier, les métadonnées, l'organisation, l'utilisation et la gestion de la zone sensible en un seul écran.
• Copy public URL se trouve désormais dans la zone File Details de l'écran d'édition, et non plus dans la colonne d'actions de la liste.
• La suppression suit le modèle standard « fenêtre modale d'administration + Danger Zone » plutôt que le balisage de confirmation du navigateur.

• Les Site Variables sont stockées de manière relationnelle dans site_variables.
• Ce sont des enregistrements ordonnés, à portée de site, dotés d'une clé, d'un libellé, d'une valeur, d'un état d'activation et d'un ordre de tri.
• La syntaxe de jeton public prise en charge est exactement {{ site.variable_key }}, avec des espaces internes facultatifs.
• Les clés sont normalisées en snake_case minuscule et doivent correspondre au motif conservateur ^[a-z][a-z0-9_]*$.
• Les jetons inconnus, les variables désactivées, les clés invalides et les jetons non liés au site restent inchangés.
• Le remplacement est une simple substitution de texte. Ce n'est pas un moteur de templates généraliste.
• Aucune condition, boucle, appel de fonction, accès à env, accès à la config, exécution de PHP, variable imbriquée ou expression arbitraire n'est prise en charge.
• Le remplacement n'intervient que lors du rendu public partagé et de l'indexation de la recherche publique.
• Les formulaires et aperçus d'administration conservent le texte du jeton tel qu'il est stocké.
• Les valeurs des variables sont traitées comme du texte brut. Dans les contextes publics acceptant le HTML, elles sont insérées en tant que texte échappé, et non comme balisage exécutable.

L'édition se fait par l'intermédiaire des slots.

Déroulement typique :

1. Créez une page.
2. Attribuez un layout.
3. Modifiez les slots du layout.
4. Ajoutez et ordonnez des blocs à l'intérieur de ces slots.

Les blocs peuvent entretenir des relations parent-enfant, ce qui permet des structures de contenu groupées sans réduire le modèle à des blobs opaques.

Les blocs sont les unités éditoriales réutilisables du CMS.

• Les données partagées portent la structure, le placement, les fichiers et les réglages opérationnels.
• Les données traduites portent le texte destiné à l'utilisateur pour chaque langue.
• Le contenu destiné à l'utilisateur n'est pas stocké dans des blobs JSON arbitraires.

Les blocs de navigation système suivent la même règle relationnelle. Navbar conserve le handle persistant sticky-navbar pour des raisons de compatibilité, mais il agit désormais comme un bloc conteneur primitif : il ne rend que nav.wb-navbar ainsi que les blocs enfants imbriqués. Il ne rend pas par lui-même le balisage de marque, les liens de menu, les actions d'en-tête ni un conteneur imposé.

La composition de la Navbar est relationnelle plutôt que pilotée par JSON :

• Navbar ne possède que la sémantique du wrapper et un réglage partagé Position.
• Container possède la contrainte de largeur. Les conteneurs hérités utilisent encore par défaut le flux empilé pour des raisons de compatibilité, mais Flow = None rend Container neutre vis-à-vis du layout, de sorte que les blocs de layout enfants contrôlent la composition.
• Cluster est la primitive de layout horizontal ou groupé. Ses réglages contrôlent la largeur, la justification, l'alignement sur l'axe transversal, le retour à la ligne et l'espacement.
• Stack reste la primitive de flux vertical.
• Navbar Brand possède le logo et le texte de marque.
• Navbar Navigation possède la sélection du menu et rend les navigation_items du site à l'aide des classes navbar de WebBlocks UI. Sur les écrans étroits, il rend également un bouton burger accessible qui ouvre le même menu via le comportement de dropdown de WebBlocks UI, tout en laissant la marque et les actions d'en-tête dans la rangée principale de la navbar.
• Header Actions, Search Form, Container et d'autres blocs compatibles peuvent être placés à l'intérieur de Navbar en tant qu'enfants si nécessaire.
• Navbar Brand et Navbar Navigation doivent se trouver quelque part dans l'arbre des ancêtres de Navbar, mais ils n'ont pas besoin d'être des enfants directs du bloc racine Navbar.
• Navbar Brand prend en charge une utilisation avec logo seul lorsqu'une image de logo existe. Lorsque le texte de titre visible est vide, un libellé accessible explicite ou le libellé résolu du site fournit le nom de repli sûr.

Composition recommandée :

• Navbar
• Container (Flow: None)
• Cluster (Width: Full, Justify: Between, Align: Center, Wrap: Nowrap)
• Navbar Brand
• Cluster (Justify: End, Align: Center, Wrap: Nowrap)
• Navbar Navigation
• Header Actions

Utilisez Container pour la largeur, Cluster pour la répartition horizontale et Stack pour le flux vertical. Navbar ne reste que le wrapper nav et n'ajoute pas de lui-même d'utilitaires de layout propres au CMS.

Cela garde la composition de l'en-tête explicite, réutilisable et alignée sur WebBlocks UI, au lieu de dupliquer une surface de conception de navbar propre au CMS.

Cela garde la propriété du contenu claire à travers le multisite, la localisation, les révisions et le rendu public.

La recherche V1 est une infrastructure publique dérivée, et non une logique de site web de la couche projet.

• La recherche n'indexe que les pages publiques publiées.
• Les lignes de recherche sont cloisonnées par site et par langue.
• La recherche utilise les traductions de page comme source de vérité pour le titre et les métadonnées d'URL publique.
• Le contenu de recherche est constitué des blocs publiés appartenant à la page, plus les blocs compatibles des Shared Slots résolus dans le contexte de la page qui les consomme.
• Les pages sources de Shared Slots masquées sont exclues de la résolution des routes publiques et des résultats de recherche autonomes.
• La première version stocke les lignes dérivées dans la table de base de données public_search_index et utilise une correspondance SQL conservatrice plutôt qu'un service de recherche externe.
• Les lignes de recherche sont des données de runtime dérivées et peuvent être reconstruites sans risque à partir du contenu du CMS.

La structure de la page publique est contrôlée au niveau de la page et du slot.

• Page Layout est le nom visible dans l'administration pour la configuration de la coque externe au niveau de la page.
• Les Page Layouts sont désormais des enregistrements gérés au niveau de l'installation, sous Admin -> System -> Page Layouts.
• Le champ de compatibilité stocké reste public_shell à cette étape, afin que les données et les handles de page existants restent valides.
• default est la coque publique standard.
• docs est la coque orientée documentation, destinée aux layouts comportant des régions d'en-tête, de barre latérale et de contenu principal.
• Les Default Layout et Docs Layout intégrés sont des layouts système préchargés avec les handles stables default et docs.
• Les pages stockent le handle du Page Layout sélectionné, et non un mode de coque résolu distinct.
• Page Layout détient désormais des jetons publics body_class optionnels et validés.
• Les Page Layout Slots sont des enregistrements relationnels au niveau de l'installation, rattachés à un Page Layout, qui définissent l'ordre des slots ainsi que les métadonnées du conteneur.
• Les Slot Types constituent le catalogue réutilisable pour l'affectation des Page Layout Slots.
• Le rendu à l'exécution résout le handle stocké vers un enregistrement Page Layout lorsqu'il est disponible, puis résout les classes du body et les conteneurs de slot à partir de ses Page Layout Slots gérés.
• Body Class est destiné au CSS propre au layout sur le <body> public, tandis que les ids et les classes des conteneurs de Page Layout Slot fournissent des points d'accroche CSS au niveau des régions à l'intérieur de ce layout.
• Le comportement sticky de la Navbar publique provient de la primitive wb-navbar livrée. Lorsqu'un slot d'en-tête public par défaut ne contient qu'un bloc Navbar, le CMS promeut le conteneur du slot en racine nav.wb-navbar, afin que le comportement sticky ne soit pas contraint par un conteneur d'en-tête supplémentaire.
• Edit Page compare les Layout Slots gérés du Page Layout sélectionné aux Page Slots actuels de la page.
• Les Layout Slots manquants peuvent être ajoutés explicitement via Add Missing Layout Slots.
• Les Page Slots excédentaires sont conservés par sécurité et signalés plutôt que supprimés.
• Les nouvelles pages utilisent les Page Layout Slots gérés actifs du Page Layout sélectionné avant de se rabattre sur les tableaux de slots hérités.
• Changer de Page Layout lors d'un enregistrement normal ne modifie pas automatiquement les Page Slots existants.
• Les Page Layouts personnalisés de la V1 peuvent utiliser des handles personnalisés, mais ils réutilisent malgré tout, de manière conservatrice, le comportement de coque default ou docs existant, par compatibilité.
• Le nom du slot détermine le rôle sémantique du conteneur public de cette région.
• Les conteneurs de slot sont résolus automatiquement à partir des Page Layout Slots gérés lorsqu'ils sont disponibles, avec des définitions de repli héritées pour les layouts intégrés. Les slots inconnus utilisent le conteneur div par défaut, qui est sûr.
• Le HTML de layout avancé et de confiance n'existe que pour le balisage structurel adjacent au conteneur. Ce n'est pas une surface de script généraliste et il ne doit pas servir à des scripts.
• Les slots d'en-tête sont neutres vis-à-vis du layout par défaut et n'imposent pas wb-stack autour de leurs arbres de blocs.
• Les slots principaux peuvent toujours porter un rythme empilé via leur partial de coque lorsque cette présentation est intentionnelle.
• L'espacement entre l'en-tête et le contenu principal appartient au conteneur de la coque publique, et non à Navbar ni à d'autres blocs d'en-tête individuels. Les conteneurs d'en-tête et principal de la coque par défaut portent ce rythme, de sorte que le premier bloc de contenu n'a pas besoin de marges supérieures ad hoc.
• Le comportement sticky de la navbar doit rester détenu par le contrat .wb-navbar livré avec WebBlocks UI. Le page layout et les conteneurs des slots d'en-tête portent la structure au niveau de la page, mais le CMS ne doit pas injecter une classe sticky de navbar parallèle.
• Les blocs affichent du contenu à l'intérieur de ces conteneurs de slot et ne doivent pas détenir la coque externe de la page.
• La validation du Page Layout autorise des extraits de conteneur de confiance pour combler des manques structurels, mais rejette les scripts, les attributs d'événement, les URL javascript: et les contenus iframe, object et embed.

Pour les pages de type documentation, utilisez le page layout plutôt que de reporter la responsabilité de la mise en page sur les blocs de contenu individuels. La recette habituelle est Page Layout = Docs Layout avec les slots Header, Sidebar et Main, afin que la coque puisse les associer automatiquement aux conteneurs de navbar, de barre latérale et de contenu principal de la documentation.

En V1, Page Layout détient le choix de la coque publique externe, les noms de slot détiennent la sémantique des conteneurs de région, et les blocs détiennent le contenu à l'intérieur de ces conteneurs.

• Les métadonnées publiques sont résolues à partir du site courant et du contexte de traduction de la page courante, et non à partir de Project Identity ni des réglages hérités et modifiables de nom ou de slogan de l'application.
• Les titres publics de page ont pour valeur par défaut Site Label · Page Label.
• L'ordre de priorité du libellé de site est : display_name du site, seo_title du site, name du site, puis une valeur de repli sûre du CMS.
• L'ordre de priorité du libellé de page est : seo_title de la traduction de la page, puis le titre de la traduction de la page.
• L'ordre de priorité de la description est : seo_description de la traduction de la page, seo_description du site, puis aucune balise de description.
• L'ordre de priorité des mots-clés est : seo_keywords de la traduction de la page, seo_keywords du site, puis aucune balise de mots-clés.
• L'ordre de priorité du titre Open Graph est : og_title de la traduction de la page, sinon le même modèle de titre public commençant par le site.
• L'ordre de priorité de la description Open Graph est : og_description de la traduction de la page, seo_description de la traduction de la page, seo_description du site.
• L'ordre de priorité de l'image Open Graph est : og_image_media_id de la traduction de la page, social_image_media_id du site, puis aucune balise og:image.
• Le média de favicon du site est inchangé et reste, à cette étape, uniquement au niveau du site.
• Les métadonnées multisite restent sensibles à l'hôte via le site public résolu ; le site principal n'est pas utilisé aveuglément lorsqu'un autre site correspond à l'hôte courant.

• La recherche publique reste limitée au site et à la langue (locale) résolus.
• Le texte de la fenêtre modale de recherche peut inclure le libellé du site résolu, afin que les utilisateurs voient dans quel site la recherche est effectuée.
• Le texte de la recherche publique utilise Site Identity, et non Project Identity.

Les Shared Slots constituent une couche de propriété du contenu des slots qui se place sous le modèle de page layout existant.

• Le page layout détermine toujours quels slots sont disponibles.
• La coque de page et le nom du slot déterminent toujours les conteneurs publics de chaque slot.
• La source de chaque slot de page peut être page, shared_slot ou disabled.
• page signifie que le slot utilise des blocs détenus directement par la page, ce qui reste le comportement actuel.
• shared_slot signifie que le slot référence un arbre de blocs Shared Slot réutilisable et limité au site, rendu dynamiquement à l'exécution publique.
• disabled signifie que le conteneur du slot existe toujours, mais qu'aucun bloc n'y est rendu.
• Les Shared Slots sont des arbres de blocs de slot réutilisables et limités au site, et non des modèles fondés sur la copie.
• Les références à des Shared Slots ne sont valides qu'au sein d'un même site. Les opérations de page inter-sites doivent être réaffectées à un Shared Slot compatible du site cible, ou se rabattre sur un résultat sûr de blocage ou de désactivation, selon l'opération et le choix explicite de l'utilisateur.
• Les Shared Slots ne détiennent ni les coques de page ni les conteneurs de slot. La coque de page détient toujours la coque externe, et le slot de page consommateur détient toujours le conteneur de header, main, sidebar ou d'autres régions de slot.
• Un Shared Slot valide n'apporte que l'arbre de blocs rendu à l'intérieur de ce conteneur de slot de page existant.
• Le rendu public des Shared Slots est conservateur :
• Les références à des shared slots d'un autre site ne rendent rien.
• Les écrans d'administration des Shared Slots décrivent la contrainte optionnelle SharedSlot.public_shell comme Page Layout, mais le nom du champ stocké reste public_shell pour des raisons de rétrocompatibilité dans cette version.
• Si SharedSlot.public_shell est défini, il doit correspondre exactement au handle du page layout consommateur.
• Si SharedSlot.slot_name est défini, il doit correspondre au nom du slot de page consommateur.
• Des valeurs nulles ou vides de public_shell et slot_name font office de correspondances génériques.
• Un handle de Page Layout personnalisé qui correspond à shell_type = docs ne correspond pas automatiquement à un Shared Slot contraint à docs en V1.

Le périmètre actuel couvre désormais les fondations, le rendu public, la gestion d'administration limitée au site, l'affectation de la source des slots de page et la prise en charge de la portabilité entre sites pour les Shared Slots.

• Les Shared Slots disposent de leur propre liste d'administration et de leurs propres formulaires de métadonnées dans la zone de contenu de site de l'administration.
• Les arbres de blocs des Shared Slots se modifient via un éditeur de blocs dédié aux Shared Slots, qui réutilise le modèle de rédaction de blocs actuel au lieu de copier le contenu dans les slots de page consommateurs.
• Les blocs des Shared Slots restent de véritables enregistrements blocks reliés par shared_slot_blocks, le texte traduit demeurant dans les tables de traduction existantes.
• La suppression d'un Shared Slot est bloquée tant qu'un slot de page y fait encore référence.
• L'éditeur de page expose désormais un sélecteur de source par slot, avec trois modes pris en charge :
• Page Content : page_slots.source_type = page et shared_slot_id = null.
• Shared Slot : page_slots.source_type = shared_slot et shared_slot_id pointe vers un Shared Slot actif et compatible du même site.
• Disabled : page_slots.source_type = disabled et shared_slot_id = null.
• Changer la source d'un slot ne supprime ni ne détache l'arbre de blocs détenu par la page pour ce slot. Si un éditeur bascule un slot vers shared_slot ou disabled, les blocs détenus par la page restent rattachés, de sorte qu'un retour à Page Content restaure le contenu propre à la page précédent.
• L'ajout des Layout Slots manquants suit le même principe de sécurité : il ne crée que de nouveaux Page Slots et ne modifie ni les slots adossés à un Shared Slot, ni les slots Disabled, ni les arbres de blocs détenus par la page.
• L'éditeur de page filtre les choix de Shared Slot de manière conservatrice. Seuls les Shared Slots actifs du même site apparaissent, et les contraintes optionnelles public_shell et slot_name du Shared Slot doivent correspondre à la coque et au nom de slot de la page consommatrice.
• Les formulaires d'administration des Shared Slots libellent désormais cette contrainte optionnelle public_shell comme Page Layout, afin que le terme visible par l'utilisateur corresponde aux écrans de l'éditeur de page et de gestion des Page Layouts.
• L'export/import et le clonage de site transfèrent toujours les handles public_shell au niveau de la page dans le cadre de la configuration de page. Les définitions de Page Layout au niveau de l'installation restent locales à l'installation en V1 ; les installations cibles devraient donc définir tout handle personnalisé qu'elles s'attendent à rendre sans repli.
• Les définitions de Page Layout Slot au niveau de l'installation restent elles aussi locales à l'installation en V1.
• Les garde-fous du rendu public à l'exécution restent en place même après la validation à l'écriture, de sorte que les affectations invalides, obsolètes, inter-sites, inactives ou incompatibles ne rendent toujours aucun contenu partagé publiquement.
• Les Shared Slots participent désormais à l'export/import et au clonage de site. Leurs métadonnées, les arbres de blocs des pages sources masquées, les traductions, l'ordre imbriqué et les références média sont transférés comme contenu de site à part entière. Les slots de page consommateurs conservent les références shared_slot par handle de Shared Slot lors de l'export et sont réaffectés aux Shared Slots du site cible lors de l'import et du clonage.
• Les pages sources masquées des Shared Slots restent internes. Elles sont exclues des charges utiles d'export de pages normales, des listes de pages ordinaires et du routage public, même si leurs enregistrements de blocs continuent d'alimenter l'éditeur de Shared Slot et les flux de portabilité.
• Les Shared Slots disposent désormais de leur propre historique de révisions et de leur propre flux de restauration, volontairement distinct des révisions de page.
• Les révisions de Shared Slot capturent les métadonnées du Shared Slot ainsi que l'arbre de blocs réutilisable du Shared Slot situé derrière la page source interne masquée.
• Restaurer une révision de Shared Slot restaure le Shared Slot sur place. L'id du Shared Slot reste stable, les références page_slots.shared_slot_id existantes demeurent intactes, et le contenu restauré affecte immédiatement toutes les pages qui référencent ce Shared Slot.
• Les révisions de Shared Slot ne considèrent pas les révisions de page comme faisant autorité pour le contenu des Shared Slots, et les révisions de page ne prétendent pas capturer les arbres de blocs des Shared Slots.

La publication du flux de travail de page et la publication des blocs sont distinctes par défaut. Publier un enregistrement de page rend la page routable lorsque ses règles de langue (locale) et de chemin correspondent, mais cela ne publie pas silencieusement les blocs en brouillon ou en cours de relecture contenus dans cette page. Les éditeurs et relecteurs peuvent ainsi publier la coque de la page tout en retenant certains blocs pour une relecture ultérieure.

Lorsqu'un utilisateur choisit explicitement d'inclure les blocs détenus par la page, WebBlocks CMS ne publie que les blocs détenus par les slots de page non partagés de cette page. Les blocs enfants imbriqués sous ces slots détenus par la page sont inclus. Les slots adossés à un Shared Slot sont exclus ; leurs arbres de blocs réutilisables doivent être relus et publiés via les flux de travail propres aux Shared Slots.

La Internal Content API suit la même règle. POST /webadmin/api/pages/{page}/publish utilise par défaut include_page_owned_blocks: false, exige content.publish et exclut les Shared Slots. Les outils d'IA ou d'opérateur ne doivent activer include_page_owned_blocks: true qu'avec l'approbation explicite de l'utilisateur.

• Site Promotion agit sur le contenu détenu par le site, et non sur l'ensemble de l'installation.
• Il peut mettre à jour des champs d'identité de site sûrs, des affectations de langue (locale), des variables de site, des pages, des traductions de page, des slots, des blocs, des Shared Slots, la navigation, des ressources de page et, en option, des ressources de fichiers du paquet.
• Il préserve les données de niveau installation et d'exécution en production telles que les utilisateurs, les sessions, les sauvegardes, l'historique des mises à jour, les soumissions de contact, les rapports de visiteurs, les domaines, les réglages d'environnement et les secrets.
• Il ne traite pas public_search_index comme du contenu portable. Les lignes de recherche sont reconstruites à partir du contenu promu après application.
• C'est un flux de travail par paquets contrôlé, et non une réplication brute de base de données.

Le cœur de WebBlocks CMS contient les fonctionnalités CMS réutilisables.

• Conservez dans project/ le code propre à l'installation qui doit survivre aux mises à jour du CMS.
• Gardez hors du cœur les commandes, vues, routes, configurations, utilitaires d'import et flux de migration propres au site lorsqu'il ne s'agit pas de fonctionnalités produit réutilisables.
• Traitez project/ comme la frontière d'extension sûre vis-à-vis des mises à jour, pour une installation donnée.
• Gardez dans le cœur le comportement produit réutilisable : blocs, layouts, interface d'administration, moteurs de rendu publics, workflow, sauvegarde/restauration, export/import et prise en charge générique de la couche projet.
• Gardez dans project/ les utilitaires de migration/import de site et l'outillage de synchronisation de contenu propre à l'installation.
• Les passerelles de migration rapide de sites web peuvent vivre dans project/ lorsqu'elles sont volontairement temporaires et propres à un site web. L'importateur de la documentation restante de WebBlocks UI en est un exemple : il stocke les fragments <main> de la documentation récupérée sous forme de HTML de confiance dans une charge utile de projet, sans rien apprendre au cœur du CMS au sujet de ce site web.
• Ce type de passerelle doit préserver le contenu curé existant du CMS, laisser le comportement de la coque ou de la navigation au CMS, et rendre explicite la frontière temporaire du HTML de confiance, afin qu'un raffinement ultérieur en blocs à part entière reste possible.
• Les paquets de version du cœur n'embarquent pas de contenu project/.

Consultez ../DEVELOPMENT.md pour le flux complet de développement et de publication.