Le développement traditionnel d’un thème WordPress repose sur la répétition des balises d’en-tête et de pied de page dans les fichiers de modèle. Chaque fois que vous mettez à jour un menu de navigation ou un élément de pied de page, vous devez localiser chaque fichier de modèle qui inclut le balisage et apporter les modifications nécessaires à plusieurs endroits. Cela entraîne des frais généraux de maintenance et augmente le risque d’incohérences sur l’ensemble de votre site.
Radicle apporte le moteur de modèle (template) Blade de Laravel à WordPress grâce à l’architecture basée sur les composants d’Acorn. Au lieu de disperser les balises dans les fichiers de modèles, vous définissez des composants réutilisables une seule fois et les référencez à travers votre thème. Lorsque vous avez besoin de mettre à jour un élément de l’interface utilisateur, vous modifiez un seul fichier de composant plutôt que de parcourir des dizaines de modèles.
Pourquoi le développement de modèles WordPress a besoin d’une architecture basée sur des composants
WordPress stocke les modèles dans une structure de répertoire de thème où header.php et footer.php apparaissent dans chaque modèle de page à travers les appels get_header() et get_footer(). Cela fonctionne pour les sites de base, mais pose des problèmes lors de la mise à l’échelle de projets complexes.
Par exemple, un site avec des types de publication personnalisés, des pages de destination et des modèles de marketing inclut les mêmes balises de navigation, la même structure de pied de page et les mêmes éléments de colonne latérale dans chaque fichier de modèle. Vous devez donc parcourir plusieurs fichiers de modèle pour ajouter un nouvel élément de menu ou mettre à jour un formulaire de contact dans le pied de page.
Radicle organise les modèles Blade sur resources/views/ avec des répertoires distincts pour les mises en page, les composants et les blocs :
components. Ce répertoire comprend des éléments d’interface utilisateur autonomes tels que des titres et des boutons.layouts. Ce répertoire contient les modèles structurels qui définissent l’échafaudage de la page.blocks.Vous y stockez les modèles de blocs qui s’intègrent à l’éditeur de site WordPress.
Cette organisation crée une source unique de vérité pour chaque élément de l’interface utilisateur. Un composant x-heading définit le balisage et le style de l’en-tête à un seul endroit. Ainsi, lorsque vous utilisez ce composant dans les modèles, Blade fait référence à la définition unique. Par extension, la mise à jour du composant met à jour chaque instance sur votre site.
Comment construire des mises en page primaires qui éliminent le code dupliqué
Au lieu de dupliquer les balises de navigation et de pied de page, vous pouvez utiliser l’héritage de modèle pour créer une mise en page parentale qui définit l’enveloppe du site.
Une mise en page commence par un fichier de composant Blade à l’adresse resources/views/components/. Le fichier layout.blade.php définit la structure HTML qui enveloppe le contenu de la page. Il comprend la section doctype, l’en-tête avec les balises méta et les références aux ressources, la structure de navigation et les éléments du pied de page. L’élément clé d’une mise en page est la variable $slot, que Blade utilise comme point d’injection du contenu.
<html>
<head>
<title>{{ $title ?? 'My Site' }}</title>
</head>
<body>
<nav>
</nav>
<main>
{{ $slot }}
</main>
<footer>
</footer>
</body>
</html>
Les modèles enfants étendent cette présentation à l’aide de la syntaxe des composants de Blade. Un modèle de page enveloppe son contenu dans les balises de composant x-layout. Blade traite cela en effectuant le rendu du composant de mise en page et en injectant le contenu de l’enfant à l’endroit où la variable $slot apparaît :
<x-layout>
<h1>Page Title</h1>
<p>Page content goes here.</p>
</x-layout>
Les emplacements nommés fournissent des points d’injection supplémentaires pour le contenu dynamique (comme les titres de page). Au lieu d’accepter un emplacement par défaut, vous définissez des emplacements spécifiques avec des noms. Le composant x-slot doté d’un attribut name transmet le contenu à ces emplacements désignés :
<x-layout>
<x-slot name="title">
Custom Page Title
</x-slot>
<h1>Page Heading</h1>
<p>Page content.</p>
</x-layout>
Le composant de mise en page accède aux emplacements nommés par le biais de variables correspondant aux noms des emplacements. Vous pouvez ainsi injecter du contenu dans plusieurs emplacements de mise en page à partir d’un seul modèle enfant.
Création de composants d’interface utilisateur réutilisables pour des modèles de conception cohérents
Les composants Blade centralisent le style et le balisage des éléments d’interface communs.
Au lieu d’écrire le balisage des boutons avec les classes Tailwind dans chaque modèle, vous créez un composant de bouton qui encapsule le balisage. Le composant accepte des « accessoires » pour la personnalisation tout en conservant un style de base cohérent.
L’utilisation du composant x-heading avec d’autres composants typographiques en est un bon exemple. Il accepte une propriété level qui détermine l’élément HTML (h1, h2, h3) et une propriété size qui contrôle l’échelle visuelle. Le composant associe ces éléments à des classes Tailwind en interne, ce qui permet de séparer les détails de l’implémentation.
<x-heading level="h1" size="3xl">
Main Page Title
</x-heading>
<x-heading level="h2" size="2xl">
Section Heading
</x-heading>
Le fichier du composant à l’adresse resources/views/components/heading.blade.php définit la logique de balisage et de stylisme en utilisant la directive @props de Blade pour définir les propriétés acceptées et leurs valeurs par défaut. Chaque composant construit l’élément HTML approprié avec des classes basées sur les valeurs des propriétés.
Un composant x-link suit le même modèle avec une variante de prise en charge des différents styles de liens, et une variante prop permet de passer de la présentation par défaut à la présentation bouton et à la présentation non stylisée.
Les composants d’interface utilisateur tels que x-button vous permettent de réaliser la même chose avec des éléments interactifs. Le composant button prend en charge la taille et les variantes pour différents styles de boutons. Lorsque vous l’associez à un framework tel qu’Alpine.js par l’intermédiaire du composant x-modal, vous pouvez gérer les interactions sans disperser le JavaScript dans les modèles :
<x-button variant="primary" @click="showModal = true">
Open Modal
</x-button>
<x-modal x-show="showModal">
<p>Modal content</p>
</x-modal>
Les accessoires conviennent bien aux chaînes de caractères, aux booléens et à d’autres données simples. Les slots conviennent mieux aux contenus complexes qui incluent des balises. Par exemple, le composant modal utilise un slot par défaut pour accepter le contenu modal complet plutôt que de faire passer du HTML par un prop.
Connecter les données WordPress aux modèles Blade avec les compositeurs de vues
Les compositeurs de vues vous permettent d’agréger des données provenant de plusieurs sources avant d’effectuer le rendu d’un modèle. Ici, vous créez une classe composer qui gère la récupération et la transformation des données plutôt que d’interroger les articles directement dans les modèles. Au lieu de cela, le modèle reçoit des données structurées à afficher.
Le modèle Post de Radicle simplifie le travail avec les données des articles WordPress en utilisant quelques méthodes différentes :
title()renvoie le titre de l’article.- La méthode
content()récupère le contenu filtré de l’article. excerpt()accepte un nombre de mots et génère un extrait.permalink()renvoie l’URL de l’article.
Pour les images mises en avant, hasThumbnail() vérifie si une image existe et thumbnail() récupère l’image HTML avec une taille spécifiée :
$post = Post::find(123);
echo $post->title();
echo $post->excerpt(30);
if ($post->hasThumbnail()) {
echo $post->thumbnail('large');
}
Les classes de compositeurs de vues se trouvent dans app/View/Composers/ et étendent RootsAcornViewComposer. La classe définit les vues auxquelles elle s’applique grâce à la propriété statique protégée $views, qui accepte un tableau de noms de modèles. Pour un compositeur de page d’accueil, vous spécifiez 'front-page' pour cibler le modèle front-page.blade.php :
namespace AppViewComposers;
use AppModelsPost;
use RootsAcornViewComposer;
class FrontPage extends Composer
{
protected static $views = ['front-page'];
public function with()
{
return [
'recentPosts' => Post::recent(6)->get(),
'totalPosts' => Post::published()->count(),
];
}
}
La méthode with() renvoie un tableau dont les clés deviennent des noms de variables dans le modèle. Les valeurs peuvent être des collections Eloquent, des modèles individuels ou n’importe quelle structure de données. Quoi qu’il en soit, cette méthode s’exécute avant que le modèle ne rende et ne prépare les données.
Le modèle front-page.blade.php accède directement à ces variables. La directive @foreach de Blade parcourt les articles en boucle, et chaque itération donne accès aux méthodes du modèle Post :
<div class="posts-grid">
@foreach ($recentPosts as $post)
<article>
@if ($post->hasThumbnail())
<img src="{{ $post->thumbnail('medium') }}" alt="{{ $post->title() }}">
@endif
<h2>
<a href="{{ $post->permalink() }}">{{ $post->title() }}</a>
</h2>
<p>{{ $post->excerpt(20) }}</p>
</article>
@endforeach
</div>
<p>Total posts: {{ $totalPosts }}</p>
Dans ce modèle, le compositeur s’occupe de l’interrogation et de la transformation des données, tandis que le modèle se concentre sur le balisage et la logique d’affichage. Lorsque vous devez modifier la structure des données ou ajouter de nouvelles requêtes, vous mettez à jour le compositeur sans toucher aux fichiers du modèle.
Construction de blocs pour l’éditeur de site WordPress avec rendu Blade
Radicle utilise le rendu côté serveur pour les blocs de l’éditeur de site grâce aux modèles Blade. Le composant éditeur JavaScript gère l’interface du bloc dans l’administration de WordPress, et le modèle Blade gère la sortie frontend.
Cela vous permet de construire des interfaces de blocs avec React (par exemple) tout en rendant le HTML de production avec Blade.
La commande wp acorn make:block génère trois fichiers pour chaque bloc :
- Une classe PHP dans
app/Blocks/gère la logique côté serveur. - Le composant JSX dans
resources/js/editor/définit l’interface de l’éditeur de bloc. - Les modèles Blade dans
resources/views/blocks/rendent la sortie frontale.
Une commande wp acorn make:block latest-posts crée LatestPosts.php, latest-posts.block.jsx, et latest-posts.blade.php. Le fichier JSX définit les attributs du bloc et les contrôles de l’éditeur, tandis que les blocs dynamiques utilisent InspectorControls pour ajouter des réglages dans la colonne latérale du bloc. Vous importez des contrôles à partir de @wordpress/components et les composez en une interface de paramétrage.
import { InspectorControls } from '@wordpress/block-editor';
import { RangeControl, ToggleControl, RadioControl } from '@wordpress/components';
export const attributes = {
posts: { type: 'number', default: 5 },
displayFeaturedImage: { type: 'boolean', default: false },
postLayout: { type: 'string', default: 'list' },
};
export const edit = ({ attributes, setAttributes }) => {
return (
<>
<InspectorControls>
<RangeControl
label="Number of posts"
value={attributes.posts}
onChange={(value) => setAttributes({ posts: value })}
min={1}
max={10}
/>
<ToggleControl
label="Display featured image"
checked={attributes.displayFeaturedImage}
onChange={(value) => setAttributes({ displayFeaturedImage: value })}
/>
<RadioControl
label="Layout"
selected={attributes.postLayout}
options={[
{ label: 'List', value: 'list' },
{ label: 'Grid', value: 'grid' },
]}
onChange={(value) => setAttributes({ postLayout: value })}
/>
</InspectorControls>
</>
);
};
Le filtre render_block dans BlocksServiceProvider.php intercepte le rendu du bloc et transmet les attributs au modèle Blade. Il reçoit également le contenu et les données du bloc. Vous vérifiez le nom du bloc, demandez les données nécessaires et renvoyez la vue Blade rendue :
add_filter('render_block', function ($block_content, $block) {
if ($block['blockName'] === 'radicle/latest-posts') {
$attributes = $block['attrs'] ?? [];
$posts = get_posts([
'numberposts' => $attributes['posts'] ?? 5,
'post_status' => 'publish',
]);
return view('blocks.latest-posts', [
'posts' => $posts,
'displayFeaturedImage' => $attributes['displayFeaturedImage'] ?? false,
'postLayout' => $attributes['postLayout'] ?? 'list',
]);
}
return $block_content;
}, 10, 2);
Le modèle Blade utilise des tableaux PHP pour gérer les mises en page conditionnelles. Ici, vous définissez les configurations de mise en page sous forme de tableaux imbriqués qui associent les noms de mise en page aux classes CSS et aux éléments HTML.
@php
$layoutConfig = [
'grid' => [
'container' => 'grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6',
'element' => 'div',
],
'list' => [
'container' => 'space-y-6',
'element' => 'div',
],
];
$config = $layoutConfig[$postLayout];
@endphp
<div class="{{ $config['container'] }}">
@foreach ($posts as $post)
<article>
@if ($displayFeaturedImage && has_post_thumbnail($post))
{{ get_the_post_thumbnail($post, 'medium') }}
@endif
<h3>{{ $post->post_title }}</h3>
</article>
@endforeach
</div>
Ce modèle crée des blocs flexibles dans lesquels les contrôles de l’éditeur ajustent la sortie frontend sans dupliquer la logique du modèle : JavaScript gère l’interface utilisateur, PHP gère les requêtes de données et Blade gère la structure du balisage.
Comment la mise en cache de Kinsta augmente les performances des vues compilées de Blade
La compilation de Blade convertit essentiellement les modèles .blade.php en code PHP simple. Une fois que Blade a terminé l’analyse complète du modèle et de la syntaxe Blade, il stocke un fichier compilé dans storage/framework/views/. Cette compilation se produit une fois par changement de modèle plutôt qu’à chaque chargement de page, mais les requêtes suivantes ignorent la compilation et exécutent le PHP mis en cache.
Le processus transforme les directives Blade en fonctions PHP. Par exemple, la directive @foreach devient une boucle foreach; la syntaxe {{ $variable }} devient une instruction echo avec échappement.
La mise en cache au niveau du serveur de Kinsta (à la fois la mise en cache edge et la mise en cache des objets Redis) fonctionne avec le cache de compilation de Blade pour créer plusieurs niveaux de performance. Les vues compilées de Blade se situent entre ces couches, qui fournissent des temps d’exécution de modèles bénéficiant à la fois de la mise en cache en amont et de l’optimisation en aval.
Pendant le déploiement, Blade efface le cache lorsque vous apportez des modifications aux modèles dans les environnements de stockage ou de production. Bien que Blade détecte les modifications de modèles pendant le développement, vos processus de déploiement devraient inclure l’effacement du cache de vue en exécutant php artisan view:clear ou wp acorn view:clear dans votre script de déploiement.
Le développement moderne de thèmes WordPress inclut Radicle et Kinsta
La combinaison de la structure inspirée de Laravel de Radicle et de l’infrastructure d’hébergement infogéré de Kinsta vous donne une base pour la mise à l’échelle des projets WordPress. Les agences qui gèrent plusieurs sites clients peuvent exploiter des modèles de composants cohérents entre les projets. Pour les développeurs, vous pouvez travailler avec les conventions familières de Laravel tout en maintenant la compatibilité avec WordPress.
L’étape suivante dépend de votre configuration actuelle. Si vous commencez à zéro, commencez par installer Radicle et créez votre premier composant Blade. Si vous migrez un thème existant, identifiez les modèles de balisage répétitifs et convertissez-les en composants, une section à la fois. Concentrez-vous sur les zones à forte valeur ajoutée telles que la navigation, les en-têtes et les pieds de page, où les avantages des composants sont immédiats.
Si vous avez besoin d’un hébergement WordPress géré qui supporte des flux de développement modernes, Kinsta offre des fonctionnalités qui fonctionnent avec des outils tels que Radicle et Acorn.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
