Mode contentOnly des blocs
Mode contentOnly des blocs limite l'édition au contenu des blocs en masquant les contrôles structurels lorsque l'éditeur le permet. Son emploi dépend des mécanismes et composants disponibles sur le site WordPress.
Comprendre et utiliser
À quoi sert ce terme ?
Mode contentOnly des blocs limite l'édition au contenu des blocs en masquant les contrôles structurels lorsque l'éditeur le permet. Son utilité concrète est de confier la rédaction des fiches à une équipe sans exposer leur architecture visuelle. Cette approche permet de cibler le bon composant et de définir le comportement attendu avant de modifier le code ou la configuration.
Fonctionnement technique
Le bloc est défini par un type, ses attributs, son rendu et les restrictions ou extensions qui lui sont associées. Selon le mécanisme étudié, la règle peut être déclarée dans block.json, appliquée dans le JavaScript de l’éditeur ou intervenir au moment du rendu. Dans le cas de « Mode contentOnly des blocs », la responsabilité particulière est de limite l'édition au contenu des blocs en masquant les contrôles structurels lorsque l'éditeur le permet. Distinguer la valeur déclarée du comportement réellement observé permet d’éviter des conclusions erronées.
Dans quel contexte l’utiliser ?
Situation professionnelle : Confier la rédaction des fiches à une équipe sans exposer leur architecture visuelle. Repérer le contenu concerné, les droits de l’utilisateur et le résultat à mesurer. Ne pas étendre le changement à l’ensemble du site sans justification.
Exemple technique commenté
Extrait pédagogique dans éditeur de blocs, pour confier la rédaction des fiches à une équipe sans exposer leur architecture visuelle. Identifier le fichier d’intégration et les dépendances avant toute adaptation ; les noms ATOOLPHA sont illustratifs. Le comportement de l’éditeur, le HTML sauvegardé et le rendu frontal doivent être distingués. Un réglage d’interface ne se substitue jamais à une vérification des capacités côté PHP. Le code montré est un fragment explicatif et peut dépendre de déclarations, hooks, imports ou fichiers non reproduits.
<InnerBlocks templateLock="contentOnly" />
Décryptage de l’exemple
L’extrait montre le point d’entrée technique par lequel on peut limite l'édition au contenu des blocs en masquant les contrôles structurels lorsque l'éditeur le permet. Il n’inclut pas forcément la déclaration du composant, le hook ou le traitement d’erreur : ces parties dépendent du projet réel.
Résultat attendu
Résultat recherché : confier la rédaction des fiches à une équipe sans exposer leur architecture visuelle. Le résultat n'est pas déclaré testé : il reste à observer dans une installation WordPress compatible.
Mise en pratique et vérification
Sur un site de test : confier la rédaction des fiches à une équipe sans exposer leur architecture visuelle. Essayer un cas normal et un cas limite, puis comparer le résultat observé au comportement annoncé. La vérification critique est : dépend du type de bloc et de la configuration; ne remplace pas les capacités.
Précautions et erreurs fréquentes
Point de vigilance : dépend du type de bloc et de la configuration; ne remplace pas les capacités. En cas d’écart, examiner le contexte d’exécution, la version de WordPress et les messages de la console ou des journaux PHP avant de modifier la configuration.
À ne pas confondre
Ne pas confondre le paramétrage d’un bloc avec un hook PHP : les deux systèmes peuvent coopérer, mais ils ne s’exécutent pas au même endroit.
Diagnostic avancé
Ouvrir une publication de test, insérer le bloc ciblé et comparer le rendu dans l’éditeur avec celui du site public, puis réouvrir la publication pour détecter une éventuelle erreur de validation. En cas de divergence, contrôler cette limite : dépend du type de bloc et de la configuration; ne remplace pas les capacités.
Architecture et maintenance
Dans l’éditeur de blocs, préciser où s’applique la configuration : métadonnées, filtre JavaScript ou propriétés d’un bloc. La même page peut réunir des blocs hérités et des blocs récents ; observer leur comportement respectif évite de généraliser un résultat. Pour cette notion, documenter les préconditions, les dépendances et la solution de repli lorsque l’API n’est pas disponible.
Termes associés
block.json, Block API, InnerBlocks, Block Context
