Twig et PHP n’ont pas besoin de se concurrencer dans un design Phoenix. Twig exprime la présentation et PHP peut préparer un traitement WordPress ou fournir un fragment précis. La difficulté consiste à donner une responsabilité claire à chaque fichier.
Commencez par les fonctions et les composants existants avant de créer un nouveau point d’entrée.
Utiliser Twig pour présenter les champs
Un bloc de présentation ordinaire peut recevoir title, description, photo et les valeurs de ses boutons. Twig permet de choisir une variante, de parcourir une liste et d’afficher ou de masquer un élément selon les données disponibles.
{% if title is not empty %}
<h2>{{ title|e }}</h2>
{% endif %}
{% for item in features|default([]) %}
<article class="md-card">
<h3>{{ item.title|e }}</h3>
<div>{{ item.description|raw }}</div>
</article>
{% endfor %}
L’éditeur du contenu ne devrait pas avoir à connaître cette boucle. Il complète le répéteur natif et le design gère sa présentation.
L’échappement reste contextuel : texte, attribut, URL et HTML éditorial ne se traitent pas tous de la même manière. Utiliser raw partout retire une protection sans expliquer la source des données.
Préférer un fragment PHP pour un besoin précis
Un petit traitement peut être plus lisible avec une API WordPress native. C’est le cas d’une image mise en avant avec ses dimensions, du rendu contrôlé d’un article classique ou d’un groupe de liens vers des pages existantes.
Le helper observé dans Phoenix charge un fichier de php/part/ :
{{ load_design('carte', 'mon-design', settings.post_id)|raw }}
Pour cet appel, le chemin attendu est designs/mon-design/php/part/carte.php. Dans l’implémentation fournie, le fragment peut lire la variable $post_id transmise.
<?php
if (!defined('ABSPATH')) { exit; }
$target = get_post((int) ($post_id ?? 0));
if ($target) {
echo '<a href="' . esc_url(get_permalink($target)) . '" title="'
. esc_attr(get_the_title($target)) . '">'
. esc_html(get_the_title($target)) . '</a>';
}
L’exemple montre un rendu local. Il ne remplace pas une vérification de visibilité lorsque vous acceptez un identifiant provenant d’un visiteur.
Comprendre ce que signifie un fallback
Un fichier PHP peut servir de solution de repli ou de présentation alternative selon le chargeur du thème. Ne supposez pas son ordre de priorité uniquement à partir de son nom : confirmez comment votre version recherche les fichiers Twig et PHP.
Le dossier php/part/ possède un appel explicite avec load_design(). Un fichier comme php/hero.php dépend du mécanisme de rendu des composants installé. Ce sont deux points d’entrée différents.
Lisez le guide d’installation lorsque vous reprenez un projet dont le bootstrap n’est pas documenté.
Garder les traitements hors du rendu
Un modèle qui affiche une page n’est pas le bon endroit pour créer des contacts, envoyer des courriels à chaque chargement ou modifier des options. Les actions doivent utiliser les hooks et les composants de traitement appropriés.
De même, un téléchargement de ZIP passe par un point d’entrée HTTP dédié. Le shortcode affiche un lien ; la réponse binaire est produite séparément. Le guide des téléchargements illustre cette séparation.
Tester les effets sur le contexte courant
Une requête secondaire peut changer le post global si elle emploie la boucle WordPress classique sans réinitialisation. Vérifiez qu’une carte ou une liste ne modifie pas le titre, les liens ou les métadonnées de la page principale.
Traitez aussi les valeurs absentes : page supprimée, média introuvable ou fonction non disponible dans une installation différente. Le fragment doit rester local et ne pas masquer une erreur fondamentale de chargement du thème.
La bonne répartition est celle qu’un autre développeur peut comprendre : données et traitements identifiables, Twig centré sur la présentation et contenu toujours administrable.
