L’en-tête et le pied de page sont consultés sur l’ensemble du site. Un lien écrit directement dans un fichier Twig devient donc rapidement une petite dépendance cachée. Phoenix permet de réutiliser les menus WordPress et les réglages globaux pour que ces éléments restent modifiables dans le backend.
La première étape consiste à identifier les sources existantes avant d’ajouter un réglage ou un nouveau formulaire.
Raccorder les emplacements de menus
Le design peut déclarer les emplacements dont il a besoin avec l’API native de WordPress. Si le thème les déclare déjà, gardez la convention en place.
add_action('after_setup_theme', static function () {
register_nav_menus([
'primary' => 'Navigation principale',
'footer' => 'Liens du pied de page',
]);
});
Cette déclaration appartient à functions.php ou à un fichier qu’il charge assez tôt. Elle ne crée pas automatiquement les menus ni leur affectation : ces choix se font dans l’administration WordPress.
Dans Twig, le design de référence emploie le helper Phoenix :
<nav aria-label="Navigation principale">
{{ menu('primary', 'md-nav-list', 'no')|raw }}
</nav>
Vérifiez le sens des paramètres dans la version de TwigExtension.php utilisée. Le troisième argument observé ici correspond à la convention du projet reçu.
Utiliser les réglages globaux déjà disponibles
Le contexte settings contient notamment le nom, le logo et les coordonnées disponibles dans l’installation. Un bouton global peut utiliser contact_us_url et contact_us_text.
{% if settings.contact_us_url and settings.contact_us_text %}
<a href="{{ url(settings.contact_us_url)|e('html_attr') }}"
title="{{ settings.contact_us_text|e('html_attr') }}">
{{ settings.contact_us_text }}
</a>
{% endif %}
La condition empêche un bouton vide. L’URL est obtenue par son identifiant et suit ainsi les mécanismes de lien déjà utilisés par Phoenix.
Pour une zone de contact secondaire, utilisez le deuxième couple de champs natifs lorsqu’il est disponible. N’inventez pas une nouvelle page de paramètres uniquement pour recopier une valeur existante.
Préparer un pied de page qui donne des repères
Le footer peut réunir une présentation courte, des menus thématiques, les coordonnées et les liens légaux. Le titre d’un groupe peut suivre le nom du menu affecté plutôt qu’une chaîne écrite dans plusieurs fichiers.
Le texte de présentation doit aussi venir d’une source administrable, par exemple un champ global déjà prévu dans le projet. La présence d’un formulaire de newsletter dans settings.newsletter permet de réutiliser son rendu et son traitement existants.
Gardez toutefois une hiérarchie claire : un footer rempli de liens sans regroupement n’aide pas le lecteur à choisir sa prochaine étape.
Soigner les noms accessibles
Le texte d’un lien doit rester compréhensible hors de son contexte immédiat. Un logo qui mène à l’accueil peut avoir un nom accessible indiquant la marque et la destination. Si le nom est déjà écrit à côté de son symbole, une image décorative peut conserver alt="".
L’attribut title demandé pour ce projet complète les liens, mais il ne remplace ni leur texte visible ni un nom accessible correct. Les menus natifs peuvent recevoir cet attribut par le filtre nav_menu_link_attributes, sans modifier chaque élément en base.
Testez les sous-menus au clavier. Le survol de souris ne doit pas être la seule façon d’accéder à une destination.
Vérifier le menu mobile comme un vrai parcours
Le bouton d’ouverture doit exposer son état, généralement avec aria-expanded, et identifier la zone contrôlée. Le JavaScript doit mettre cet état à jour lorsque le menu change.
Essayez un lien long, plusieurs sous-entrées et une taille de texte agrandie. Assurez-vous que les liens légaux et le contact restent atteignables sur téléphone.
Le raccordement est réussi lorsque l’équipe peut changer un lien, le logo et le bouton global dans WordPress, puis voir ces changements partout sans ouvrir le code.
