Gutenberg est depuis quelques années le nouvel éditeur par défaut de WordPress. Il vise à rendre l’expérience plus puissante et intuitive afin de s’approcher des solutions intuitives telles que Wix.

Si vous souhaitez en savoir plus sur l’historique de Gutenberg ou apprendre à l’utiliser, je vous suggère la lecture de cet article. En tant que développeur, deux questions se posent :

• faut-il adopter Gutenberg ?
• comment créer un thème compatible ?

Gutenberg or not ?

C’est une question assez récurrente depuis le début du projet. De nombreux développeurs (et utilisateurs) n’ont pas été séduits par Gutenberg et préfèrent l’éditeur classique. Cet éditeur donne moins de contrôle à l’utilisateur final mais c’est aussi l’assurance de ne pas s’écarter de la charte graphique.

En tant que développeur, pour les sites que j’administre moi-même, j’affectionne l’éditeur classique lorsqu’il est en mode code avec la coloration syntaxique. Je peux y mettre directement du HTML ou du markdown et c’est à peu près tout ce dont j’ai besoin pour le contenu.

Par ailleurs, les champs personnalisés se chargent des détails qui ne peuvent pas être gérés directement au sein de l’éditeur principal.

Cependant, pour les clients, le HTML n’est souvent pas une option. Dès lors, tout dépend de la typologie et de la complexité du site. Gutenberg peut s’avérer être une très bonne solution, il faut cependant que le thème configure l’environnement de manière à ce que l’ensemble des blocs soient adaptés.

Par défaut, certaines options permettent de changer les tailles et les couleurs, c’est souvent l’assurance de finir avec un site “sapin de noël” si l’administrateur n’a pas une grande sensibilité au design.

Créer un thème Gutenberg

Sans rien faire, votre thème est déjà compatible avec Gutenberg. L’éditeur fonctionne en back-office et les blocs s’affichent correctement sur le front. Cependant, certaines options doivent être explicitement déclarées comme compatibles afin qu’elles soient utilisables.

En outre, comme nous l’avons dit, il est possible de déclarer ses propres styles, de désactiver certaines options et d’ajouter nos propres blocs.

Vos propres styles

Gutenberg ajoute ses propres styles. Cela permet aux blocs d’avoir un design minimaliste et fonctionnel quel que soit le thème. Cependant, votre thème peut tout à fait compléter ou écraser ces styles pour certains ou tous les blocs.

Si vous souhaitez totalement supprimer les styles par défaut, vous pouvez désactiver le CSS de Gutenberg via un hook.

add_action('wp_enqueue_scripts', function () {
    wp_dequeue_style('wp-block-library');
});

Tous les blocs seront alors totalement bruts. Il vous faudra tous les styliser manuellement.

Align modes

Certains blocs, comme le bloc image, offrent plusieurs largeurs supplémentaires : grande largeur et pleine largeur. Pour que ces options soient proposées, il faut que vous déclariez le thème comme compatible.

add_theme_support('align-wide');

Dès lors, il faut évidemment ajouter les styles nécessaires à votre thème afin qu’il gère ces options. Les deux classes vous permettant d’adapter ces styles sont respectivement .alignwide et .alignfull.

Options du thème

Gutenberg propose des options de couleurs et de tailles par défaut. Votre thème peut désactiver ces options et ajouter les siennes. En effet, il est tout à fait logique de vouloir contraindre l’éditeur à ne pas sortir de la palette de couleur de la charte graphique par exemple.

Ces nombreuses options, qui se déclaraient traditionnellement via le hook theme_support sont depuis WordPress 5.8 toutes déclarables depuis un seul et unique fichier : theme.json. Vous pouvez utiliser ce générateur afin de rapidement créer votre theme.json.

Feuilles de style de l’éditeur

L’objet de Gutenberg est de proposer un éditeur qui reflète au maximum ce que l’on voit sur le front du site. Pour cela, vous pouvez ajouter une feuille de styles spécifique à l’éditeur.

Attention, n’importez pas tous les styles destinés au front dans l’éditeur, vous risqueriez d’avoir un affichage totalement cassé. Cependant, comme certains styles seront partagés, l’idéal est d’avoir un moteur de styles tel que Less ou Sass afin de pouvoir importer certains modules aussi bien en front qu’en back.

Une fois votre feuilles de styles créée, déclarez simplement cette dernière de manière classique dans votre fichier functions.php.

add_theme_support('editor-styles');
add_editor_style('styles/editor.min.css');

Contraindre les blocs utilisables

Il est tout à fait possible que vous vouliez désactiver certains blocs : ils n’ont pas d’usage sur le site ou sont inadaptés. C’est bien entendu possible. On utilise pour cela le hook allowed_block_types_all.

add_filter('allowed_block_types', function ($allowed_blocks) {
    // On déclare ici tous les blocs que l'on souhaite autoriser
    return [
        'core/buttons',
        'core/columns',
        'core/cover',
        'core/group',
        'core/heading',
        'core/image',
        'core/more',
        'core/paragraph',
        'core/list',
        'core/shortcode',
        'core/spacer',
        'core/video'
    ];
});

Voici l’ensemble des blocs disponibles par défaut actuellement (de nouveaux blocs peuvent être créés).

• core/archives
• core/audio
• core/button
• core/buttons
• core/calendar
• core/categories
• core/classic
• core/code
• core/column
• core/columns
• core/cover
• core/file
• core/latest-comments
• core/latest-posts
• core/legacy-widget
• core/gallery
• core/group
• core/heading
• core/html
• core/image
• core/list
• core/media-text
• core/more
• core/navigation
• core/navigation-link
• core/nextpage
• core/paragraph
• core/preformatted
• core/pullquote
• core/quote
• core/rss
• core/search
• core/separator
• core/shortcode
• core/social-link
• core/social-links
• core/spacer
• core/subhead
• core/table
• core/tag-cloud
• core/text-columns
• core/verse
• core/video
• core/widget-area

Par ailleurs, certains plugins peuvent ajouter leurs propres blocs. Ainsi, pour récupérer la liste de tous les blocs disponibles, on peut faire un var_dump.

var_dump(
    WP_Block_Type_Registry::get_instance()->get_all_registered()
);

Modifier les options des blocs

Certains blocs possèdent des variantes de style. Concrètement, ces variantes ajoutent simplement une classe au conteneur du bloc, permettant l’application d’un style alternatif.

Il est possible de supprimer une variantes d’un bloc mais aussi d’en ajouter. On utilisera pour ce faire register_block_style et unregister_block_style.

// On ajoute un style "justification" au bloc paragraphe
register_block_style('core/paragraph', [
    'name' => 'justify',
    'label' => 'Justifier'
]);

Ici, il faudra bien entendu prévoir d’appliquer des styles (en front et au sein de l’éditeur) afin que le nouveau style de bloc prenne effet lorsque la classe est ajoutée.

// Ici on supprime "fancy quotes" du bloc citation
unregister_block_style('core/quote', 'fancy-quote');

Créer un bloc sur-mesure

Avoir la possibilité de créer ses propres blocs est un réel plus pour offrir une expérience flexible et personalisée. De la même manière que WordPress fournit un theme.json depuis sa version 5.8, il est dorénavant possible de déclarer un bloc via block.json.

Les différentes fonctions et méthodes sont toutes expliquées dans le documentation. Par ailleurs, pour accélérer la création d’un bloc, il est possible d’utiliser le scaffold de la wp-cli.

Étant donné que la technique standard est assez longue et fastidieuse (bien qu’elle présente le plus d’options). Nous allons voir qu’il est aussi possible de créer des blocs via certains plugins de custom fields (ACF et Carbon Fields par exemple).

ACF étant le plus populaire, voyons comment déclarer un nouveau bloc ACF en quelques lignes. Prenons l’exemple d’un bloc permettant de déclarer une image de background.

On déclare tout d’abord un nouveau bloc ACF depuis le fonctions.php. Je ne vais pas ici expliquer toutes les options disponibles, vous pouvez évidemment les retrouver dans la documentation ACF.

add_action('acf/init', function () {
    acf_register_block_type([
        'name' => 'bgimage',
        'title' => 'Image décorative',
        'description' => 'Utilisation d\'une image décorative qui "remplit l\'espace"',
        'mode' => 'edit',
        'render_callback' => 'bgimage',
        'category' => 'formatting',
        'icon' => 'format-image',
        'keywords' => ['image', 'content']
    ]);
});

Puis depuis le back-office, on va créer la logique de ce bloc directement depuis ACF.

Et c’est tout, vous avez un bloc fonctionnel prêt à recevoir du contenu. Il ne vous reste plus qu’à créer le CSS afin de styliser votre nouveau bloc.

Créer des pattern

Sachez déjà qu’il est possible directement depuis l’interface de sauvegarder des blocs que vous avez pré-configurés afin de les réutiliser rapidement plus tard.

Cependant, il est aussi possible de créer un template complet et de le déclarer au sein du thème afin qu’il soit toujours accessible. Un peu à la manière des templates que nous connaissons.

Vous commencez par simplement créer le layout qui vous convient dans l’éditeur Gutenberg. Une fois cela effectué, vous affichez le code brut depuis le menu option (en haut à droite) et copiez tout le code. Nous allons maintenant déclarer ce pattern avec la fonction register_block_pattern.

Depuis le functions.php, on place tout le code du template dans une variable. N’hésitez pas à utiliser heredoc ou nowdoc si le code de la template est complexe.

$template_code = '…';

register_block_pattern(
    'buzut/mon-block-custom', // le nom du bloc pattern, il faut qu'il soit unique
    [
        'title' => 'Mon Super Bloc',

        // le nom de la catégorie dans laquelle le bloc sera rangée
        // on peut créer nos propres catégories
        'categories' => ['formatting'],
        'content' => $template_code,
        'description' => '…',
        'keywords' => '…',

        // Le viewport du bloc utilisé pour la visualisation dans l'éditeur
        'viewportWidth' => 1000
    ]
);

Voilà, vous retrouvez maintenant votre template directement depuis l’éditeur, prêt à être utilisé !

Déclarer un template

De la même manière qu’on le fait avec les custom post type pour certains types ou modèles de pages, il est possible de proposer un template pré-fabriqué pour certaines pages. Ainsi l’utilisateur n’a plus qu’à ajouter son contenu.

Lorsque l’on enregistre un nouveau type de contenu via register_post_type, on peut passer des options permettant de définir un template Gutenberg.

add_action('init', register_post_type('book', [
    'public' => true,
    'label'  => 'Sports',
    'show_in_rest' => true,

    // On va ici déclarer un modèle
    'template' => [
        [
            'core/paragraph',
            ['placeholder' => 'Insérez votre contenu']
        ],
        [
            'core/image',
            ['align' => 'center']
        ],
        [
            'core/button'
        ]
    ],
    'template_lock' => 'all'
]));

Cette dernière option permet d’autoriser ou non la modification du template. Il est par ailleurs possible d’imbriquer les templates.

Étant donné que l’on voudra également créer des templates pour des post types existants, il est possible de définir un template pour ces posts.

add_action('init', function() {
    $post_type_object = get_post_type_object('post');
    $post_type_object->template = [
        [
            'core/paragraph',
            ['placeholder' => 'Add Description…']
        ]
    ];

    // Et si l'on veut verrouiller le template
    $post_type_object->template_lock = 'all';
});

À ma connaissance, il n’est pas possible de cibler une taxonomie comme on peut le faire avec les templates classiques. Par ailleurs, si la différence entre bloc, pattern et template vous semble floue, n’hésitez pas à lire cet article du blog officiel WordPress.

Dans le prochain chapitre, on change un peu de sujet pour se concentrer sur les performances.