Installer un design Phoenix consiste à raccorder des fichiers de présentation à un environnement WordPress déjà capable de charger les composants. Copier un dossier Twig ne suffit pas si le thème, les dépendances ou les champs attendus ne sont pas disponibles.
Ce guide propose un contrôle progressif, utile aussi lorsque vous reprenez un projet existant.
Vérifier ce qui est réellement installé
Identifiez la version de WordPress, le thème actif et les composants PHP du projet. Lisez le fichier composer.json du thème ainsi que son fichier de verrouillage lorsqu’il existe. Ils constituent la référence pour les dépendances et leurs contraintes.
Vérifiez la disponibilité d’ACF et des fonctions utilisées par l’installation, notamment les blocs et les champs flexibles. Les exemples fournis ne contiennent ni le cœur Phoenix ni une copie d’ACF. Les accès aux dépôts privés et les licences éventuelles se règlent avec l’équipe qui fournit la solution.
Travaillez sur une copie de développement avec une sauvegarde. Une installation déjà en service peut comporter des modifications locales à préserver.
Placer le design au bon niveau
Le dossier de présentation appartient à designs/nom-du-design/, dans le thème Phoenix. Le kit proposé contient un sous-dossier mon-design à copier, et non un thème autonome à téléverser dans l’écran des thèmes WordPress.
wp-content/themes/phoenix/
designs/
mon-design/
functions.php
parts/
php/
assets/styles.json
Si designs/ est déjà un dépôt Git, commencez par regarder son état. Ne remplacez pas son contenu avec une archive sans comparer les fichiers. Le guide d’organisation propose une répartition adaptée.
Confirmer le mécanisme de sélection du design
Les ressources de référence mentionnent un fichier designs/design.json. Certaines installations exposent aussi des réglages de design. Vérifiez le bootstrap réellement utilisé avant de modifier ces valeurs : la présence d’un champ dans l’administration ne prouve pas qu’il prend la priorité dans toutes les versions.
Lorsque votre chargeur lit ce fichier, la sélection peut ressembler à ceci :
{
"design": "mon-design"
}
Le même contrôle s’applique à functions.php : confirmez qu’il est chargé assez tôt pour brancher les hooks nécessaires. Évitez d’inclure un second moteur Twig pour contourner une erreur de sélection.
Tester un bloc avant la page complète
Créez une page de test avec un seul hero, un titre identifiable et une description courte. Vérifiez que le rendu public vient bien du fichier parts/hero.twig attendu.
Ajoutez ensuite une photo et un bouton interne. Changez le texte dans WordPress et confirmez le résultat. Cette étape vérifie simultanément le chargement du design, le passage des champs et la résolution des liens.
Si le bloc reste vide, examinez son nom technique dans DefaultValues.php, les données du bloc et le chemin du fichier. Le guide de diagnostic aide à isoler ces causes.
Contrôler les ressources et les menus
Ouvrez les outils du navigateur et cherchez la feuille CSS déclarée dans assets/styles.json. Sa requête doit réussir, avec un contenu CSS valide. Répétez l’opération pour le JavaScript. Un chemin système de serveur ne peut pas remplacer une URL publique.
Affectez ensuite un menu aux emplacements prévus et renseignez les réglages Phoenix existants : nom, logo, coordonnées et boutons globaux. Le design de démarrage livré ici utilise ces sources ; il n’ajoute pas de page de réglages propre à l’exemple.
Valider un premier état stable
La préparation est terminée lorsque vous pouvez modifier le titre d’une page, changer sa photo, utiliser le menu et activer son bouton sur ordinateur et téléphone. Gardez cette petite page comme scénario de référence avant d’ajouter d’autres sections.
Vous pouvez maintenant créer un premier bloc de présentation et élargir le design à partir d’un fonctionnement vérifié.
