final class MetadonneesPage {
public function __construct(
public readonly string $titre,
public readonly string $description,
public readonly string $canonical
) {}
}
Cette classe de quelques lignes règle un problème récurrent sur les projets où le titre, la description et l’URL canonique d’une page sont calculés à trois endroits différents du thème, parfois par des développeurs différents, à des moments différents du cycle de requête. PHP 8.1, sorti fin novembre 2021, introduit les propriétés readonly qui rendent ce genre d’objet réellement immuable une fois construit.
Voici l’architecture complète de cet objet-valeur, pensée pour un développeur backend qui centralise ces trois métadonnées avant qu’elles ne soient affichées dans le <head> du thème — l’affichage lui-même relevant d’une autre couche, non traitée ici.
Le problème que cette architecture résout
Sur un thème sans structure claire, le titre peut être défini par un filtre document_title_parts, la description par une fonction accrochée à wp_head, et le canonical par un filtre get_canonical_url encore différent. Rien n’empêche ces trois points de code d’entrer en contradiction : un canonical qui pointe vers une page dont le titre a été calculé pour une autre URL, par exemple, en cas de logique dupliquée ou mal synchronisée entre les trois filtres.
La classe centrale

L’objet MetadonneesPage devient l’unique source de vérité pour ces trois valeurs. Une fois construit, aucune de ses propriétés ne peut être modifiée : toute tentative déclenche une erreur, ce qui élimine par construction toute une catégorie de bugs liés à une modification tardive et non maîtrisée.
$metadonnees = new MetadonneesPage(
titre: 'Guide complet du filtre document_title_parts',
description: 'Comment personnaliser le titre affiché par WordPress sans extension.',
canonical: home_url( '/guide-document-title-parts/' )
);
// $metadonnees->titre = 'Autre titre'; // Error: Cannot modify readonly property
La fabrique qui construit l’objet
Une classe fabrique centralise la logique de calcul, en s’appuyant sur les données de l’article WordPress courant :
final class FabriqueMetadonnees {
public static function depuisArticle( \WP_Post $article ): MetadonneesPage {
$titre = get_the_title( $article );
$description = has_excerpt( $article )
? get_the_excerpt( $article )
: wp_trim_words( $article->post_content, 25 );
return new MetadonneesPage(
titre: $titre,
description: $description,
canonical: get_permalink( $article )
);
}
}
Ce que cette architecture apporte concrètement
- Un seul point d’entrée à tester unitairement, plutôt que trois filtres dispersés dans le thème
- Une garantie structurelle contre les modifications accidentelles après construction, grâce à
readonly - Une base réutilisable pour d’autres types de contenu (page, taxonomie) via d’autres méthodes de fabrique
Étendre l’objet à d’autres types de contenu
La même fabrique peut être complétée par d’autres méthodes statiques, chacune produisant le même type d’objet MetadonneesPage à partir d’une source différente : une page de taxonomie, une page de résultats de recherche, ou une archive d’auteur.
final class FabriqueMetadonnees {
public static function depuisTerme( \WP_Term $terme ): MetadonneesPage {
return new MetadonneesPage(
titre: $terme->name,
description: wp_trim_words( term_description( $terme ), 25 ),
canonical: get_term_link( $terme )
);
}
}
Cette extensibilité découle directement du fait que l’objet MetadonneesPage ne connaît rien de sa source : il ne fait qu’exposer trois propriétés en lecture seule, quel que soit le type de contenu qui les a produites.
Les limites de cette approche
Cet objet ne remplace pas les filtres natifs de WordPress comme document_title_parts : il constitue plutôt la source de données que ces filtres viendront lire au moment de l’affichage. Sa valeur tient dans la centralisation du calcul, pas dans le remplacement du mécanisme d’affichage lui-même, qui reste couplé aux hooks natifs du cœur.
Le principe qu’on applique désormais sur nos thèmes maison : toute donnée calculée à plusieurs endroits mérite un objet unique qui en devient la seule source de vérité.
En résumé
Centraliser titre, description et canonical dans un objet-valeur immuable élimine un défaut d’architecture fréquent : la dispersion de la même logique dans plusieurs filtres qui finissent par se contredire. Les propriétés readonly de PHP 8.1 rendent cette centralisation robuste, en empêchant structurellement toute modification tardive une fois l’objet construit.