Créez des paramètres de personnalisation plus rapidement en utilisant le framework Kirki dans votre projet

Publié: 2019-08-10

Kirki est un framework open source gratuit (sous licence MIT) conçu pour les développeurs qui cherchent à ajouter des contrôles de personnalisation à leurs thèmes ou plugins.

Aristeides Stathopoulos, le développeur principal de Kirki, travaille sur le framework depuis 2014. Grâce aux mises à jour et améliorations continues, Kirki a construit une communauté sur Github qui comprend plus de 1000 étoiles et 300 fourches.

Avant Kirki, je n'avais jamais touché au customiseur. Kirki m'a aidé à comprendre le personnalisateur et à faire beaucoup en moins de temps !

LebCit – Développeur de thèmes WordPress

Contrôles du personnalisateur de base de WordPress

WordPress Core inclut par défaut une poignée de contrôles de personnalisation de base. Par exemple : texte, zone de texte, case à cocher, radio, sélection, pages déroulantes, e-mail, URL, nombre, masqué et contrôles de date.

Kirki prend également en charge les Core Controls, ainsi qu'une vingtaine d'autres. De manière générale, les contrôles Kirki couvrent les cas d'utilisation les plus avancés. Par example:

  • Typographie
  • Palettes de couleurs
  • Éditeur TinyMCE
  • Champs triables

Kirki propose également des fonctionnalités non disponibles dans Core WordPress, telles que la génération automatique de votre sortie CSS et des scripts postMessage. Ces fonctionnalités, que nous aborderons plus loin dans cet article, peuvent facilement réduire de moitié votre temps de développement.

Kirki est lent

Une critique communément adressée à Kirki est qu'il est lent. En fait, cette critique est utilisée contre la plupart des frameworks (y compris WordPress). C'est logique, non? Vous chargez beaucoup de code que vous n'utiliserez peut-être jamais.

Dans ce cas, la réalité est que le contraire est vrai. La plupart du temps, les panneaux de contrôle construits avec Kirki seront en fait plus rapides que les mêmes panneaux construits avec Core Controls.

En effet, Kirki ajoute une couche d'optimisation qui n'est pas intégrée à WordPress.

Lorsque le Customizer est initialisé, WordPress essaie instantanément de charger tous les contrôles, même s'ils se trouvent dans une section ou un panneau et que l'utilisateur ne peut pas encore interagir avec eux. En comparaison, Kirki reporte le chargement juste avant que l'utilisateur n'interagisse avec le contrôle.

Pour voir l'effet de cela dans la pratique, essayons d'ajouter 50 contrôles de couleur en utilisant chaque méthode.

Méthode de base :

 pour ($i = 0; $i < 50; $i++){
	$wp_customize->add_setting( 'color_setting_hex_' . $i , array(
		'default' => '#0088CC'
	) );

	// ajoute le contrôle du sélecteur de couleurs
	$wp_customize->add_control( new WP_Customize_Color_Control( $wp_customize, 'color_setting_hex_' . $i, array(
		'label' => 'Contrôle des couleurs',
		'section' => 'title_tagline',
		'settings' => 'color_setting_hex_' . $i,
	) ) );
}

Avec Kirki :

 pour ($i = 0; $i < 50; $i++) {
     Kirki :: add_field( 'config_id', array(
         'type' => 'couleur',
         'settings' => 'color_setting_hex_' . $i,
         'label' => __( 'Contrôle des couleurs', 'kirki' ),
         'section' => 'title_tagline',
         'default' => '#0088CC',
     ) );
 }

Les résultats:

Comme vous pouvez le constater, la vitesse de chargement initiale est considérablement plus rapide lors de l'utilisation de Kirki. Le code requis pour créer les contrôles est également plus concis.

Intégrer Kirki dans votre projet

Il existe plusieurs façons d'intégrer le Kirki Framework dans votre projet, la documentation officielle explique bien les différentes méthodes.

Je recommande aux développeurs de guider l'utilisateur pour installer la version plugin de Kirki, plutôt que d'inclure le framework directement dans le code de votre projet. Cela peut être fait en utilisant TGMPA ou le script fourni.

Le raisonnement derrière la route du plugin est que Kirki est fréquemment mis à jour et amélioré. En installant la version du plug-in, vos utilisateurs auront un accès instantané aux correctifs de bogues et aux mises à jour de sécurité.

En revanche, lorsque vous incluez le framework dans votre projet, les utilisateurs ne recevront des mises à jour que lorsque vous mettez à jour votre thème ou votre plugin, ce qui peut être moins fréquent que nécessaire.

Quelle que soit la méthode que vous utilisez, assurez-vous de vérifier que Kirki est initialisé avant d'ajouter vos paramètres :

 // Sortie anticipée si Kirki n'existe pas.
if ( ! class_exists( 'Kirki' ) ) {
    retourner;
}

Des champs

Dans l'exemple de la méthode principale, nous avons d'abord créé un paramètre, puis créé un contrôle pour celui-ci. Dans la plupart des cas, les deux sont directement liés. Kirki simplifie le processus et nous permet de créer un "Champ" à la place. Lorsqu'un champ est créé, il crée le paramètre et le contrôle en arrière-plan pour nous.

Les champs prennent en charge tous les arguments de contrôle que vous attendez (étiquette, description, section, défaut), ainsi que certains arguments spécifiques à Kirki.

L'argument 'type' vous permet de choisir l'un des 30 types de contrôle de Kirki : https://kirki.org/docs/controls/

Sections

Les sections de personnalisation vous permettent de regrouper les contrôles. WordPress a six sections intégrées dans lesquelles vous pouvez également ajouter vos contrôles :

  • title_tagline – Identité du site
  • couleurs – Couleurs
  • header_image - Image d'en-tête
  • background_image - Image d'arrière-plan
  • static_front_page – Paramètres de la page d'accueil
  • custom_css – CSS supplémentaire


Les sections de Kirki fonctionnent exactement de la même manière que dans Core, la méthode Kirki :: add_section() est simplement un wrapper pour $wp_customize->add_section() et accepte les mêmes paramètres et arguments.

 Kirki :: add_section( 'section_id', array(
     'title' => esc_html__( 'Ma rubrique', 'kirki' ),
     'description' => esc_html__( 'Description de ma section.', 'kirki' ),
 ) );

Panneaux

Les panneaux vous permettent de créer un autre niveau de hiérarchie en regroupant les sections. WordPress Core a un panneau intégré, qui est "Menus".

Encore une fois, l'implémentation de Kirki est simplement un wrapper pour la fonctionnalité Core.

 Kirki ::add_panel( 'panel_id', array(
     'priorité' => 10,
     'title' => esc_html__( 'Mon panneau', 'kirki' ),
     'description' => esc_html__( 'Description de mon panneau', 'kirki' ),
 ) );

'transport' => 'auto'

Traditionnellement, lors de la création de contrôles de personnalisation, vous avez deux options pour l'argument de transport :

  • Actualiser – Chaque fois que l'utilisateur apporte une modification, le volet d'aperçu est actualisé pour afficher les modifications. Cela peut prendre quelques secondes.
  • postMessage - Chaque fois que l'utilisateur apporte une modification, le volet de prévisualisation est mis à jour à l'aide de Javascript, qui ne nécessite pas d'actualisation et est quasi instantané.

postMessage est sans aucun doute la meilleure méthode pour mettre à jour l'aperçu et doit être utilisé dans la mesure du possible. Cependant, il y a un inconvénient, l'utilisation de postMessage signifie que vous devez créer un code JS personnalisé pour chacun de vos contrôles. Une implémentation simple ressemble à ceci :

 // Mettre à jour le titre du site en temps réel...
wp.customize( 'nom du blog', fonction( valeur ) {
    value.bind( fonction( newval ) {
        $( '#site-title a' ).html( newval );
    } );
} );

Lorsque vous avez beaucoup de réglages, cela peut vite devenir répétitif.

C'est là que Kirki brille, il ajoute une troisième option : 'transport' => 'auto'.

'transport' => 'auto' fonctionne avec un autre argument que Kirki ajoute nommé 'output'. Lorsque les deux valeurs sont définies, Kirki générera automatiquement les scripts postMessage pour vous. Ce qui signifie que vous bénéficiez de tous les avantages de l'utilisation de postMessage sans avoir à écrire de code Javascript.

Un champ utilisant transport => 'auto' ressemble à ceci :

 Kirki :: add_field( 'config_id', array(
     'type' => 'couleur',
     'settings' => 'color_setting_hex',
     'label' => __( 'Contrôle des couleurs', 'kirki' ),
     'section' => 'couleurs',
     'default' => '#0088CC',
     'transport' => 'auto',
     'sortie' => tableau(
         déployer(
             'élément' => 'corps',
             'propriété' => 'couleur de fond',
         ),
     ),
 ) );

Cette fonction de gain de temps de Kirki signifie que la plupart du temps, vous n'aurez plus besoin d'écrire ou de mettre en file d'attente vos propres scripts postMessage.

Sortie CSS frontale

Une autre partie de la création des paramètres de personnalisation consiste à générer la sortie CSS sur le frontend. Un exemple simple pourrait ressembler à ceci :

 /**
 * Sortir le CSS du Customizer vers wp_head
 */
fonction wptavern_customizer_css() {
	$bg_color = get_theme_mod( 'color_setting_hex' );
	?>
	<style>
		corps {
			couleur de fond : <?php echo sanitize_hex_color( $bg_color ); ?> ;
		}
	</style>
	<?php
}
add_action( 'wp_head', wptavern_customizer_css );

Comme dans l'exemple postMessage, l'écriture de ce code peut rapidement devenir répétitive si vous avez beaucoup de paramètres.

Heureusement, 'transport' => 'auto' s'occupe également de la sortie frontale pour vous. Même dans notre exemple simplifié, 'transport' => 'auto' a réduit le code que nous devons écrire d'environ 50 %.

Conclusion

Dans cet article, nous avons examiné uniquement les bases du framework Kirki et deux de ses arguments, nous pouvons déjà voir comment il nous permet de créer des contrôles de personnalisation plus rapidement et sans compromettre les performances.

Lorsque vous plongerez dans Kirki, vous découvrirez rapidement la richesse des fonctionnalités qu'il ajoute en plus de l'API de personnalisation. Il n'est pas surprenant qu'il soit utilisé sur plus de 300 000 sites Web et qu'il fasse partie intégrante de certains des plus grands thèmes WordPress du marché.