Page Layouts

Les Page Layouts sont des définitions au niveau de l'installation qui gèrent le choix de la coque publique externe et les conteneurs de slots gérés des pages.

Portée de la V1

  • Chemin d'administration : Admin -> System -> Page Layouts
  • Accès : super_admin uniquement
  • La V1 prend en charge la liste, la création, la modification, l'activation, la désactivation, l'ordonnancement, le CRUD des Page Layout Slots gérés, la comparaison des slots dans Edit Page et l'application sûre des slots manquants
  • La V1 ne permet pas de supprimer les layouts système
  • Dans cette version, les pages stockent toujours le handle du layout sélectionné dans pages.settings.public_shell par rétrocompatibilité
  • Les champs visibles du Page Layout sont Name, Handle, Description, Status, Sort Order et Body Class
  • Shell Type, Slot Schema JSON et Wrapper Schema JSON sont des champs de compatibilité obsolètes et ne font plus partie du formulaire d'administration
  • Le Slot Schema JSON et le Wrapper Schema JSON bruts ne sont plus le modèle d'édition de l'administration

Layouts intégrés

  • default / Default Layout : coque standard de page publique
  • docs / Docs Layout : coque de documentation avec correspondance des régions header, sidebar, main et footer

Ces layouts intégrés restent compatibles avec les pages, imports, exports et rendus publics antérieurs.

Chaque layout intégré alimente également des Page Layout Slots gérés :

  • default : header, main, sidebar, footer
  • docs : header, sidebar, main, footer

Comment fonctionne le rendu

  • Une page stocke un handle de Page Layout dans public_shell
  • À l'exécution, ce handle est résolu en un Page Layout géré lorsqu'il en existe un
  • Le Page Layout résolu peut fournir un body_class validé à l'élément <body> public
  • À l'exécution, les conteneurs de slots sont résolus depuis les page_layout_slots relationnels lorsqu'ils sont disponibles
  • Chaque Page Layout Slot référence une ligne SlotType publiée du CMS et définit des métadonnées de conteneur telles que l'élément, l'id, les classes et des extraits de conteneur de confiance
  • Si les Page Layout Slots relationnels ne sont pas disponibles, les définitions de repli intégrées maintiennent le rendu de default et docs stable

Dans la V1, les layouts personnalisés réutilisent toujours le comportement de la coque publique default ou docs existante. Par compatibilité, le runtime déduit ce comportement de façon prudente à partir des définitions de slots gérés.

Page Layout Slots gérés

Les Page Layout Slots sont les enregistrements de région gérés rattachés à un Page Layout.

  • Chemin d'administration : Admin -> System -> Page Layouts -> Edit -> Page Layout Slots
  • Les Slot Types constituent le catalogue permettant d'ajouter des Page Layout Slots
  • Chaque Page Layout Slot stocke slot_type_id, slot_name, label, description, html_element, html_id, html_classes, before_html, start_html, end_html, after_html, is_required, is_active, is_system et sort_order
  • L'édition dans l'administration regroupe ces champs en Slot Identity, Wrapper Markup, Advanced Trusted Layout HTML et Status / Ordering
  • La validation n'autorise que des id HTML sûrs, des classes sûres séparées par des espaces et des extraits de conteneur de confiance ; les scripts, attributs d'événement, javascript:, iframe, object et embed sont rejetés
  • Les layouts système conservent une correspondance de slots système stable : les Page Layout Slots système n'autorisent pas la modification du nom de slot sous-jacent ni du Slot Type
  • Les Page Layout Slots non système et non obligatoires peuvent être supprimés
  • CSS Classes attend des jetons de classe séparés par des espaces
  • Les classes du conteneur peuvent inclure des indications de layout telles que wb-sidebar, wb-dashboard-main ou wb-stack lorsqu'elles conviennent au layout sélectionné
  • Le comportement collant de la Navbar publique doit venir de la primitive wb-navbar livrée, et non de règles sticky d'en-tête au niveau du site
  • Lorsqu'un slot d'en-tête public par défaut ne contient qu'un bloc Navbar, le CMS promeut le conteneur du slot à la racine nav.wb-navbar afin que la Navbar reste collante sans CSS propre au site
  • Before Slot HTML est rendu avant le conteneur du slot
  • Slot Start HTML est rendu dans le conteneur, avant les blocs
  • Slot End HTML est rendu dans le conteneur, après les blocs
  • After Slot HTML est rendu après le conteneur du slot
  • Le HTML de layout de confiance avancé sert uniquement au balisage de layout adjacent au conteneur, pas aux scripts

Comparer et appliquer dans Edit Page

  • Edit Page affiche désormais une carte Page Layout Slots près de la gestion des slots
  • La carte compare les Page Layout Slots gérés actifs du Page Layout sélectionné aux Page Slots actuels de la page
  • La comparaison indique au moins :
  • les Layout Slots définis par le Page Layout sélectionné
  • les Page Slots déjà présents sur la page
  • les Layout Slots manquants
  • les Page Slots supplémentaires non définis par le Page Layout sélectionné
  • les Page Slots désactivés
  • les Page Slots adossés à un Shared Slot
  • Add Missing Layout Slots n'apparaît que lorsqu'il manque des Layout Slots
  • L'action est explicite. Enregistrer les réglages normaux de la page ne synchronise pas les slots en silence.

Règles de sûreté

  • Add Missing Layout Slots ne crée sur la page courante que les Page Layout Slots actifs manquants
  • Il ne supprime pas les Page Slots supplémentaires
  • Il ne supprime pas de blocs
  • Il ne modifie pas le page_slots.source_type existant
  • Il n'efface pas le shared_slot_id existant
  • Il n'active pas automatiquement les Page Slots désactivés
  • Il ne réordonne ni ne réécrit silencieusement les Page Slots existants
  • Les Page Slots supplémentaires sont préservés et signalés par sécurité, même si le Page Layout sélectionné ne les définit pas
  • La compatibilité des Shared Slots reste exacte selon le handle public_shell stocké

Valeurs par défaut des nouvelles pages

  • Les nouvelles pages utilisent, lorsque c'est possible, les Page Layout Slots gérés actifs du Page Layout sélectionné
  • Le repli hérité slot_schema ne subsiste que comme repli de compatibilité sûr lorsque les définitions de slots gérés relationnelles ou intégrées sont indisponibles
  • Les nouvelles pages ne devraient pas obliger les administrateurs à ajouter manuellement les slots standard après avoir choisi un Page Layout

Changements de Page Layout sur les pages existantes

  • Changer le Page Layout sélectionné sur une page existante ne supprime ni ne réécrit automatiquement les slots lors d'un enregistrement normal
  • Après l'enregistrement, Edit Page affiche la comparaison mise à jour pour que les éditeurs examinent en toute sûreté les slots manquants ou surnuméraires
  • La version actuelle privilégie délibérément l'action explicite Add Missing Layout Slots plutôt qu'une mutation automatique

Body Class

  • Body Class est une liste facultative de jetons séparés par des espaces ajoutée au <body> public
  • Les valeurs intégrées actuellement générées sont layout-default et layout-docs
  • Le rendu public conserve la classe de base wb-public-body et y ajoute les classes body du Page Layout lorsqu'elles sont disponibles
  • Le CSS propre à un layout peut cibler des combinaisons telles que body.layout-docs plus les ids et classes de slot définis par les Page Layout Slots
  • Préférez un bloc Navbar pour les en-têtes publics collants ; le CMS promeut les slots d'en-tête par défaut ne contenant qu'une Navbar à la racine nav.wb-navbar, afin que WebBlocks UI gère le décalage collant et l'empilement

Frontières de responsabilité

  • Le Page Layout est responsable du choix de la coque publique externe
  • Le Page Layout est aussi responsable des jetons de classe body publics de cette coque
  • Les Page Layout Slots sont responsables des métadonnées et de l'ordre des conteneurs de région
  • Les Page Layout Slots sont responsables de l'élément conteneur public, de son id, de ses classes et du HTML de confiance optionnel adjacent au conteneur de chaque région
  • Les noms de slots sont responsables de la sémantique du conteneur de région, comme header, main, sidebar et footer
  • Les blocs sont responsables du contenu rendu à l'intérieur de ces conteneurs
  • Le comportement collant de la navbar reste du ressort de .wb-navbar de WebBlocks UI, et non des Page Layouts du CMS

Layouts inconnus ou absents

  • Les pages existantes ne sont pas migrées hors de public_shell
  • Les handles de layout inconnus restent stockés tels quels
  • L'édition dans l'administration reste sûre en affichant le handle hérité actuel comme option conservée
  • Le rendu public se rabat en toute sûreté au lieu de planter
  • Dans la V1, les handles inconnus se rabattent en toute sûreté sur le comportement d'exécution par défaut

Compatibilité avec les Shared Slots

Dans la V1, la compatibilité des Shared Slots reste prudente.

  • Les écrans d'administration des Shared Slots présentent désormais cette contrainte comme Page Layout, tandis que le champ de compatibilité stocké reste public_shell par rétrocompatibilité dans cette version
  • Une correspondance exacte du handle public_shell est requise lorsqu'un Shared Slot définit public_shell
  • Un public_shell vide reste générique
  • Un handle de layout personnalisé qui réutilise le comportement d'exécution de type docs ne correspond pas automatiquement aux Shared Slots restreints à docs
  • Ajouter les Layout Slots manquants crée de nouveaux Page Slots en Page Content par défaut et n'élargit pas le comportement de compatibilité des Shared Slots

Frontière de portabilité

  • L'export/import de sites et le clonage transfèrent toujours les handles public_shell au niveau de la page comme configuration de page
  • Dans la V1, les définitions de Page Layout et de Page Layout Slot au niveau de l'installation ne sont pas incluses dans l'export/import de sites
  • Si une page transférée utilise un handle de layout personnalisé, l'installation cible devrait disposer d'un handle de Page Layout correspondant pour obtenir le comportement voulu
  • Si aucun layout correspondant n'existe sur l'installation cible, le rendu se rabat en toute sûreté