Fait avec Chinaski

Stacks

Les stacks sont le système de construction réutilisable au cœur de l'éditeur de blocks de Chinaski. Un stack est un groupe nommé et ordonné de blocks que vous assignez une fois et réutilisez sur les pages et les posts : une section hero, une grille de fonctionnalités, un ensemble d'appels à l'action qui devrait vivre sur chaque page produit. Dans Chinaski ce sont des stacks, avec imbrication, héritage, contenu par langue et historique de révisions. Cette page explique comment les construire et les gérer.

Construire un stack

Créez un stack sous Stacks dans la zone d'administration :

  • Donnez-lui un nom (unique parmi les stacks qui n'ont pas été supprimés), une description et sa langue.
  • Ajoutez-lui des blocks depuis l'éditeur de blocks, dans l'ordre où ils doivent se rendre.
  • Donnez optionnellement au stack une enveloppe Layout JSON : une configuration de balisage du style {"tag":"section","class":"my-cta"} qui enveloppe une fois le groupe de blocks rendu.

Les stacks peuvent également inclure d'autres stacks imbriqués, chacun avec son propre ordre de tri. Un stack peut aussi étendre un autre : l'enfant préfixe les blocks du parent devant les siens, de sorte qu'une section de site partagée puisse être assemblée une fois et étendue au cas par cas. Si le stack parent est supprimé, le lien de l'enfant est effacé automatiquement.

Une note sur les éditeurs et les stacks : les stacks sont délibérément contrôlés. Si la liste des entités autorisées d'un éditeur exclut les stacks, il ne peut ni voir ni modifier aucun écran de stacks ; le contrôle s'applique aussi bien à la lecture qu'à l'écriture.

Assigner des stacks au contenu

Les stacks s'attachent depuis l'éditeur Blocks à une page ou un post. Lors de l'assignation d'un stack, des réglages par appairage existent : la position où le stack apparaît, les surcharges par instance, et (avancé) un JSON de règles de disponibilité. Chaque stack attaché est suivi par le build, de sorte que le manifeste de build signé du site enregistre quels stacks ont été utilisés par page.

Chaque block du stack peut porter des surcharges par instance, de sorte que le même block peut apparaître avec un contenu différent dans différents stacks. Et une page ne peut pas rendre le même block deux fois via la résolution des stacks : un block déjà affiché par un stack est ignoré partout ailleurs où il apparaît pendant la construction de cette page.

Stacks par langue

Les stacks tiennent compte de la langue de deux façons :

  • Le stack lui-même porte un champ de langue, de sorte que des stacks parallèles pour différentes langues peuvent exister. Les références de block à l'intérieur se résolvent par langue, avec repli sur un block vide de langue (à l'échelle du site) lorsque cette langue n'a pas de block portant le nom référencé.
  • Une traduction de stack (définie par stack + langue) fournit une liste de blocks alternative pour cette langue uniquement. Lorsqu'une traduction existe pour la langue de service, elle remplace entièrement la séquence de blocks de base pour cette langue en remplaçant les surcharges de chaque block listé. Pas de ligne de traduction : l'ordre de base l'emporte.

Imbrication et héritage

  • Les stacks imbriqués permettent à un stack d'embarquer d'autres stacks, chacun avec son ordre de tri. Le builder les résout récursivement et se protège contre les boucles infinies et les chaînes d'une profondeur absurde (plus de cinq niveaux de profondeur), de sorte qu'une mauvaise configuration ne puisse pas bloquer un build.
  • L'extension sert à la structure réutilisable : créez un stack qui étend un autre (un parent avec d'autres préfixés) ; la suppression du parent efface le lien de l'enfant proprement plutôt que de le corrompre.

Où c'est utilisé et ce qui a changé

Le tableau de bord Stacks montre où chaque stack est utilisé : la liste « used on » nomme les pages et les posts (avec un plafond des N premiers et une note lorsque la liste est plus longue). Les écrans d'édition montrent des stacks de changements récents ; chaque changement est capturé dans les révisions du stack, de sorte que vous puissiez comparer deux révisions et restaurer une configuration antérieure vers un stack en ligne.

Qualité et audits en coulisses

Chaque rendu de stack fait partie du scan de qualité du build ; les rendus de stack contribuent aux comptages d'accessibilité et de liens cassés à l'échelle du site affichés dans le build guard, et chaque restauration/mise à jour/changement de stack est journalisé dans la piste d'audit (les entrées « stack restauré vers la révision sélectionnée » sont auditées). Lorsqu'un rapport de build signale une dégradation, les stacks triés contribuent et font partie des statistiques par stack issues des mêmes données que celles utilisées pour bloquer une mauvaise promotion.

Lisez ce site en