Table des matières
- Le problème / Le besoin
- L’approche naïve (et pourquoi l’éviter)
- La bonne approche
- Variantes et cas d’usage
- Compatibilité Divi 5
- Pièges courants
- Ressources
- FAQ
Le problème / Le besoin
WordPress 6.7 introduit une nouvelle façon de gérer les blocs personnalisés dans l’éditeur Gutenberg. Si vous avez déjà tenté de créer un plugin ou un thème qui ajoute ses propres blocs, vous savez que la gestion des styles et des scripts peut devenir complexe. À la fin de cet article, vous saurez comment intégrer proprement des blocs personnalisés, avec une structure modulaire et performante.
L’approche naïve (et pourquoi l’éviter)
Souvent, les développeurs débutants ajoutent des styles et des scripts directement dans les fichiers PHP ou utilisent wp_enqueue_script et wp_enqueue_style sans condition. Cela fonctionne pour des projets simples, mais cela peut impacter les performances et la maintenabilité. Par exemple :
// Exemple simpliste à éviter
function my_custom_block_assets() {
wp_enqueue_script('my-block', plugins_url('block.js', __FILE__), array('wp-blocks', 'wp-element'));
wp_enqueue_style('my-block-style', plugins_url('style.css', __FILE__));
}
add_action('enqueue_block_editor_assets', 'my_custom_block_assets');
Ce code enregistre les ressources sans vérifier si elles sont nécessaires, chargeant potentiellement des fichiers inutiles. En outre, sans mécanisme de versionnement, les navigateurs peuvent ne pas recharger les scripts mis à jour.
La bonne approche
Pour une meilleure gestion, il est crucial d’utiliser des dépendances et de versionner correctement vos actifs. Voici un exemple de code qui montre comment faire :
// Code optimisé pour enregistrer les assets des blocs
function my_optimized_block_assets() {
// Versionner les fichiers avec le timestamp pour éviter le cache
$version = filemtime(plugin_dir_path(__FILE__) . 'block.js');
// Enregistrement du script du bloc avec les dépendances requises
wp_enqueue_script(
'my-block',
plugins_url('block.js', __FILE__),
array('wp-blocks', 'wp-element', 'wp-editor'),
$version
);
// Enregistrement du style du bloc
wp_enqueue_style(
'my-block-style',
plugins_url('style.css', __FILE__),
array(),
$version
);
}
add_action('enqueue_block_editor_assets', 'my_optimized_block_assets');
Dans cet exemple, nous utilisons filemtime pour générer une version basée sur le dernier changement du fichier. Cela assure que le navigateur recharge le fichier lorsque vous le modifiez. Nous avons aussi ajouté des dépendances appropriées pour s’assurer que les scripts sont chargés dans le bon ordre.
Variantes et cas d’usage
Voyons quelques variations et comment ces techniques peuvent s’adapter à différentes situations :
1. Chargement conditionnel
Pour éviter de charger du code inutile, vous pouvez conditionner l’enregistrement des assets :
// Exemple de chargement conditionnel
function my_conditional_block_assets() {
if (is_admin()) {
wp_enqueue_script('my-admin-block', plugins_url('admin-block.js', __FILE__), array('wp-blocks'), '1.0.0');
}
}
add_action('enqueue_block_editor_assets', 'my_conditional_block_assets');
2. Utilisation de Webpack pour la gestion des assets
Pour des projets plus complexes, utilisez Webpack pour gérer les assets JavaScript et CSS de manière modulaire.
3. Intégration avec des bibliothèques tierces
Lorsque vous avez besoin d’utiliser des bibliothèques tierces, enregistrez-les comme dépendances :
// Exemple avec une bibliothèque tierce
function my_third_party_block_assets() {
wp_enqueue_script(
'my-third-party-lib',
'https://cdn.jsdelivr.net/npm/some-lib@latest',
array(),
null
);
wp_enqueue_script(
'my-block-with-lib',
plugins_url('block.js', __FILE__),
array('wp-blocks', 'my-third-party-lib'),
'1.0.0'
);
}
add_action('enqueue_block_editor_assets', 'my_third_party_block_assets');
4. Utilisation de fichiers séparés pour l’éditeur et le front-end
Il est souvent utile de séparer les styles et scripts pour l’éditeur Gutenberg et le front-end :
// Exemple de séparation des assets
function my_editor_and_front_assets() {
// Editor styles and scripts
wp_enqueue_script('my-editor-block', plugins_url('editor-block.js', __FILE__), array('wp-blocks'), '1.0.0');
wp_enqueue_style('my-editor-style', plugins_url('editor-style.css', __FILE__), array(), '1.0.0');
// Front-end styles and scripts
wp_enqueue_script('my-frontend-block', plugins_url('frontend-block.js', __FILE__), array('wp-blocks'), '1.0.0');
wp_enqueue_style('my-frontend-style', plugins_url('frontend-style.css', __FILE__), array(), '1.0.0');
}
add_action('enqueue_block_editor_assets', 'my_editor_and_front_assets');
add_action('wp_enqueue_scripts', 'my_editor_and_front_assets');
Cette approche garantit que vous ne chargez que ce qui est nécessaire pour chaque contexte.
Compatibilité Divi 5
Divi 5, avec son constructeur de thèmes, a ses spécificités. Lors de l’enregistrement de blocs personnalisés, assurez-vous d’utiliser les hooks de Divi pour la compatibilité :
// Exemple spécifique à Divi 5
function my_divi_block_assets() {
if (function_exists('et_builder_enqueue_script')) {
et_builder_enqueue_script('my-divi-block', plugins_url('divi-block.js', __FILE__), array('et-builder-modules-global-functions-script'), '1.0.0');
}
}
add_action('et_builder_enqueue_scripts', 'my_divi_block_assets');
Utilisez toujours et_builder_enqueue_script pour garantir que les scripts s’intègrent correctement dans Divi.
Pièges courants
Un problème courant est l’oubli de désenregistrer les scripts et styles par défaut de WordPress avant d’enregistrer les vôtres, ce qui peut entraîner des conflits. Assurez-vous de vérifier les scripts et styles chargés par défaut. Vous pouvez utiliser wp_deregister_script ou wp_deregister_style si nécessaire.
// Désenregistrement d'un script par défaut
function my_custom_deregister_scripts() {
wp_deregister_script('jquery');
}
add_action('wp_enqueue_scripts', 'my_custom_deregister_scripts', 100);
Un autre piège est le manque de vérification des dépendances, ce qui peut conduire à des erreurs JavaScript si les dépendances ne sont pas correctement chargées. Vérifiez toujours que vos scripts sont listés après leurs dépendances.
Une erreur fréquente est de ne pas utiliser le bon contexte pour l’enregistrement des scripts et styles, par exemple, en utilisant wp_enqueue_scripts pour le back-end. Assurez-vous d’utiliser enqueue_block_editor_assets pour l’éditeur et wp_enqueue_scripts pour le front-end.
Ressources
- Documentation officielle de l’éditeur de blocs
- Référence de la fonction wp_enqueue_script
- Référence de la fonction wp_enqueue_style
- Concepts de Webpack
- Documentation officielle Divi
FAQ
Q : Pourquoi utiliser filemtime pour le versionnement ?
R : Cela permet de forcer le rechargement des fichiers par le navigateur en cas de modification, évitant ainsi les problèmes de cache.
Q : Comment gérer les dépendances avec des bibliothèques tierces ?
R : Enregistrez-les comme dépendances dans wp_enqueue_script pour garantir le bon ordre de chargement.
Q : Comment éviter de charger des scripts inutiles sur les pages sans blocs personnalisés ?
R : Utilisez des conditions pour vérifier le contexte d’affichage, par exemple avec is_singular() ou d’autres vérifications spécifiques à votre logique d’affaires.