Visite guidée du customizer

Pour faire simple et au cas vous n'auriez vraiment rien vu à ce sujet, c'est pour personnaliser son site.

Ça existe depuis WordPress 3.4 « Grant Green », en juin 2012. Rien que ça.

Personnaliser quoi ?

Si vous avez déjà jeté un œil au customizer, vous aurez vu que certains objets personnalisables existent par défaut :

  • le titre du site et sa description ;
  • les menus ;
  • les widgets ;
  • les options pour la page d'accueil statique.

Et si vous avez regardé ce que propose Twenty Seventeen, vous aurez aperçu d'autres objets personnalisables :

  • les couleurs ;
  • les options de mise en page…

Entrons un peu dans les détails.

Deux poids, deux mesures

Il existe deux types d'objets personnalisables grâce au customizer : les options, et les modifications du thème.

Pourquoi ?

À cause du territoire des fonctionnalités, un concept qui doit vous parler si vous utilisez — voire crééz — des thèmes ou extensions régulièrement.

Pour résumer :

  • une option est valable pour le site, indépendamment du thème actif : c'est le cas du titre du site, du slogan, etc.
  • une modification de thème… Je ne vous fais pas un dessin

Règle No

  1. Dans un thème, vous ne devriez jamais déclarer d'option.
  2. Dans une extension, vous ne devriez jamais déclarer une modification de thème.

Mode d'emploi


Un objet personnalisable est composé de deux éléments, qu'on définit grâce à l'api du customizer.


Un réglage

Il gère le comportement.


$wp_customize->add_setting('boosted_variant',
    array(
        'type'       => 'theme_mod',
        'capability' => 'edit_theme_options',
        'default'    => '',
        'transport' => 'refresh'
    )
);

Lecture : les réglages dans le handbook

Un contrôle

C'est l'interface dans le customizer.


$wp_customize->add_control('boosted_variant',
    array(
        'label'   => __("Use Boosted's black variant", "boosted"),
        'type'    => 'checkbox',
        'section' => 'title_tagline'
    )
);

Lecture : les contrôles dans le handbook

Ce dont on ne parlera pas


Parce que flûte, c'est long et j'ai pas le temps !


Les panneaux

Nous pourrions évoquer les panneaux, qui permettent d'ajouter un niveau supplémentaire — comme c'est le cas pour les menus — mais en fait, non. Il est recommandé de ne pas s'en servir dans un thème.

Lecture : les panneaux dans le handbook

Les types personnalisés

Il est également possibile de créer ses propres types de contrôles, si les champs existants ne suffisent pas. Mais c'est long, chiant, et documenté.

Lecture : les types personnalisés dans le handbook

Côté ux


Vous aurez peut-être remarqué un gros problème : l'aperçu n'est rien qu'une grosse iframe (sans vouloir l'offenser).

Ainsi quand vous modifiez ou enregistrez un réglage, la fenêtre se recharge complètement.

De plus, vous pouvez naviguer dans l'aperçu :

  • changer de page,
  • actionner des choses,
  • ouvrir des menus,
  • etc.

Autant de raison de se perdre dans cet entrelacs d'options !

Fonction d'appel

Autrement connu sous le sobriquet de active_callback


active_callback permet de définir une condition pour l'affichage d'un réglage ou d'une section. Et chose logico-magique, il mange des fonctions de template. 


$wp_customize->add_section('boosted_archives', array(
    'title'           => __("Template for posts list", "boosted"),
    'description'     => __("Define how to display content lists", "boosted"),
    'priority'        => 105,
    'capability'      => 'edit_theme_options',
    'active_callback' => function() {
      return (is_archive() || is_home());
    },
) );

Démo !

Rafraîchissement sélectif

Qu'on nomme aussi selective refresh


En définissant le transport du réglage sur postMessage, on peut lui attribuer un template partiel, qu'on ciblera ensuite grâce à un sélecteur — jQuery — et sera « rechargé » (via ajax) grâce à une fonction passée à render_callback. 


$wp_customize->get_setting('blogname')->transport = 'postMessage';
$wp_customize->selective_refresh->add_partial('blogname',
  array(
    'selector'        => 'strong[itemprop="name"]',
    'render_callback' => function () {
      bloginfo('name');
    },
  )
);

Démo !

Revenons à nos moutons


Or donc, nous pouvons :

  • naviguer sur le site dans le customizer,
  • afficher les options et modificateurs disponibles pour la page affichée,
  • et mettre à jour l'aperçu sans recharger la page.

Aurais-je omis de préciser que tout ceci fonctionne également avec les sidebars et widgets ?
Lesquels, depuis WordPress 4.8 « Evans » peuvent contenir du texte riche, du son, de la vidéo, etc.

Vous me voyez venir là, ou pas ?

Hommage à Gutenberg

Laissez moi formuler ça

Pour un template donné, que nous affublerions de moults sidebars — mises en forme comme il se doit — nous pourrions alimenter en contenus riches n'importe quelle zone de la page affichée.

Et la méga classe : on peut permettre à un thème de rafraîchir sélectivement n'importe quel widget  ! 


add_theme_support('customize-selective-refresh-widgets');

Démo !

Oui je sais, il faudrait affecter les sidebars à une page spécifique et pas simplement à un template…

Conclusion


On peut aller encore plus loins, avec notamment :

  1. les starter_content : ils sont conçus spécialement pour ça ;
  2. le choix des couleurs et caractères de typographie proprement, en structurant son css intelligement à base de inherit, currentColor et autres --var() ;
  3. l'api JavaScript, qui sert par exemple :
    • dans JetPack, à recharger un scroll infini dans un widget affichant un flux asynchrone ;
    • dans TwentyThirteen, à réinitialiser une mise en page Masonry.

Alors, qu'est-ce qu'on attend ?

Merci

Et à bientôt ☺

Crédits