Tutoriel : Advanced Custom Fields En Pratique – Le Guide Complet

Suite de mon précédent article d’introduction à Advanced Custom Fields et son intégration sur votre site, cette fois-ci nous allons découvrir une utilisation pratique de l’extension ACF. Nous irons plus loin dans les fonctionnalités d’ACF, en associant des champs à des types d’articles personnalisés, tout ça avec pas mal de code et un peu d’huile de coude. Le but : que par cet exemple vous réalisiez toutes les possibilités d’ACF et que vous puissiez l’implémenter vous-même pour vos propres besoins.

Il serait préférable que vous ayez quelques notions de développement WordPress et PHP pour pouvoir réaliser une partie de ces modifications et comprendre comment les appliquer pour vos propres besoins.

Dans cet article je vous propose d’aller plus loin avec ACF que le simple ajout d’un ou deux champs personnalisés sur des articles afin de pouvoir les afficher.

Nous allons créer un nouveau type de publication et personnaliser intégralement son contenu grâce à ACF et son affichage grâce aux modèles de WordPress. Le but est surtout de vous faire une démonstration de ce qu’il est possible de faire simplement par le code avec ACF.

En gros, vous pourriez utiliser WordPress comme base pour gérer des offres d’emploi, des événements, des biens immobiliers, des articles à louer, etc. avec pour chaque objet, d’autres liens possibles avec d’autres objets.

Pourquoi ne pas offrir à votre visiteur la possibilité de postuler pour une offre d’emploi, avec chaque postulation enregistrée et gérable dans l’administration ? Les capacités d’ACF sont très, très nombreuses, si vous maîtrisez un peu le code.

On pourrait même envisager d’accéder au contenu du site et des champs personnalisés depuis l’API de WordPress, pour récupérer ces offres d’emploi et les afficher sur un autre site ou dans une application mobile !

Je m’emballe un peu, pour notre exemple nous prendrons un cas pratique un peu plus simple, consistant à gérer et afficher une liste d’événements.

Ces événements n’auront que peu de personnalisation, mais encore une fois, il s’agit de vous ouvrir aux possibilités offertes en illustrant un exemple simple.

Description du cas pratique

Gérer des événements sur un site WordPress

Je m’inspire d’un de mes projets pour réaliser ce cas pratique : imaginons que vous créez un site Internet pour une salle de concert, de spectacle ou pour un festival.

Un des prérequis sera forcément de pouvoir gérer l’affichage d’événements (concerts, pièces de théâtre, etc.) qui auront lieu à certaines dates, heures et endroits, avec un artiste, une photo, une description, etc.

Pour ce faire, nous allons créer un type de publication personnalisé appelé Événement, qu’il sera possible de modifier depuis l’administration de WordPress au travers d’un menu Événements.

Comme pour des articles ou des pages, une interface complète d’ajout d’événement vous permettra à vous, ou à votre client de gérer les différents concerts affichés sur le site.

Pour ce type de publication, nous créerons un groupe de champ dans ACF, qui s’occupera de gérer :

• Le titre du concert ou du spectacle (nom de l’artiste, de la pièce, etc.)
• La date et l’heure de l’événement
• Un type d’événement (par exemple concert, théâtre, etc.)
• Une description complète
• Une photo illustrative

Nous verrons aussi qu’il n’est pas forcément nécessaire de réinventer la roue et que certains champs préexistants de WordPress pourront être utilisés également.

Réaliser ce cas pratique sans ACF

Avant de commencer, est-ce qu’il ne serait pas possible, nativement, de gérer des événements dans WordPress sans passer par Advanced Custom Fields ?

Oui, c’est possible. D’ailleurs la première étape consistera à enregistrer un nouveau type de publication appelé Événement, vous n’aurez pas besoin d’ACF pour faire cette opération, il s’agit de capacités natives de WordPress.

Une fois qu’un nouveau type de publication est créé, il est possible de le laisser se comporter comme un article standard, avec un titre, du contenu (la description), une image mise en avant (la photo illustrative).

Et hop, 3 des champs nécessaires pour nos événements sont déjà disponibles nativement dans WordPress. Et ensuite ?

Copier les publications

La première solution serait de créer une publication de base pour les événements, créée avec l’éditeur de WordPress directement ou avec un builder quelconque (Divi, Elementor, etc.).

Une fois que votre publication de base vous plaît, vous la copiez en cas de nouveau concert et vous modifiez son titre, son contenu et sa photo.

Pour afficher la liste de ces événements, il vous faudra certainement passer par un builder, mais c’est possible et vous devriez pouvoir le faire en utilisant un module de blog quelconque ou avec les fonctions natives de WordPress.

Mais que se passe-t-il si vous souhaitez modifier le visuel de tous vos événements ? Vous allez devoir jouer du CSS pour pour pouvoir faire des modifications et, si la structure HTML de l’événement doit changer, bon courage !

En gros, cette solution est capable de faire le travail, mais elle n’est pas pérenne et dynamique.

Utiliser les champs personnalisés de WordPress

Voici une solution un peu plus dynamique ! Les champs personnalisés de WordPress vous permettent de créer de nouveaux champs sur vos publications. Vous ne pourrez pas personnaliser leur type cela dit, il s’agira uniquement de champs de texte.

Mais ça peut suffire à faire ce dont vous aurez besoin.

Pour conserver cet aspect dynamique, on va oublier l’option de la création manuelle du modèle, au sein duquel vous devriez de toute manière faire appel à du code pour afficher les champs personnalisés de vos articles.

Il faudra, comme nous allons le faire avec ACF par la suite, passer par des modèles personnalisés que vous aurez créés vous-mêmes.

Soit en utilisant un thème Builder comme Divi qui permet de créer des modèles par type de publication ou en codant vous-même votre propre modèle.

Dans les deux cas, vous pourrez faire appel aux champs personnalisés, soit avec les options de Divi, soit avec du code.

Alors il semblerait après tout que les fonctions natives de WordPress feraient très bien l’affaire et se comportent sensiblement comme ACF ? Sur le fond oui, car ACF enregistre les champs personnalisés de la même manière que ceux de WordPress.

Par contre, il y a de nombreux inconvénients aux champs personnalisés natifs :

• Vous ne pourrez pas gérer leur format. Un champ de date ou une case à cocher, WordPress s’en fout, l’utilisateur peut saisir ce qu’il veut. À vous de vous débrouiller avec.
• Il n’y a aucune validation de format non plus
• Impossible de spécifier des champs obligatoires
• L’interface de gestion des champs personnalisés n’est pas pratique du tout
• Vous devrez passer beaucoup plus de temps dans le code pour valider et formater manuellement ces champs
• Et pleins d’autres choses qu’ACF fait très bien

En résumé, pourquoi se rendre la vie difficile alors qu’ACF, dans sa version gratuite, installée en quelques secondes, vous enlève une grosse épine du pied en vous permettant de gérer tout ça très facilement ?

Développement du cas pratique

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants avant de commencer :

• Un thème enfant avec un fichier functions.php
• Le module Advanced Custom Fields installé et activé
• Une petite connaissance de PHP et du code de WordPress est un gros plus

Pas encore de thème enfant ? Pas de panique, vous pouvez utiliser mon générateur de thème enfant pour WordPress pour vous faciliter la vie et en générer un en quelques secondes.

Si vous voulez en savoir un max sur ACF avant de débuter, lisez mon tutoriel d’introduction sur le sujet.

Pour en vous familiariser avec les modèles WordPress, vous pouvez consulter mon article complet sur la modification manuelle des modèles d’articles. Et le même article vous expliquant la même procédure avec Divi 4.0.

Ce cas pratique est là pour vous donner les clés nécessaires pour profiter de la puissance d’ACF, si vous avez envie de sortir un peu du script que j’ai établi, en créant vos champs différemment ou en ajoutant d’autres, n’hésitez pas.

En gros, soyez créatif !

Envie d’accélérer le processus ?

Téléchargez le squelette d’un thème WordPress personnalisable

Ce squelette de thème enfant entièrement commenté vous guidera pour vous permettre de personnaliser votre site jusqu’à l’os 🙂

E-mail

Télécharger

1. Créer un nouveau type de publication

Première étape pour ce tutoriel, il s’agira de créer un nouveau type de publication appelé Événement. Cette première étape n’est pas spécifique à Advanced Custom Fields et pour être honnête, elle est tout à fait optionnelle.

Lorsque vous créez des champs dans ACF, vous devez préciser pour quel type de publication affiché ces champs. Afin d’avoir un contrôle total et pour créer une interface d’administration consistante, j’ai pour habitude de créer de nouveaux types de publication.

Mais vous pourriez simplement créer une catégorie Événement dans les catégories d’articles et ajouter de nouveaux articles dans cette catégorie. Ensuite la condition d’affichage des champs ACF se ferait sur les articles de cette catégorie.

En créant votre propre type de publication comme nous allons le faire, vous aurez la possibilité d’avoir un menu personnalisé pour gérer ces publications :

Pour enregistrer un nouveau type de publication, ouvrez votre fichier functions.php et ajoutez-y le code suivant :

function create_custom_post_type() {
   register_post_type( 'event',
      array(
         'labels' => array(
            'name' => __( 'Événements' ),
            'all_items' => __('Tous les événements'),
            'singular_name' => __( 'Événement' )
         ),
         'public' => true,
         'has_archive' => true,
         'rewrite' => array('slug' => 'events'),
         'supports' => array ('title', 'revisions', 'thumbnail'),
         'menu_icon' => 'dashicons-tickets',
         'publicly_queryable' => true,
      )
   );
}

add_action( 'init', 'create_custom_post_type' );

Pour résumer on crée une méthode create_custom_post_type() qui s’occupe d’enregistrer un nouveau type de publication, plus bas on ajoute cette méthode à l’action init de WordPress avec add_action.

L’action init s’exécute dans WordPress à la fin du chargement de celui-ci, une bonne partie des plug-ins et widgets sont instanciés durant cette action.

Au sein de la méthode que nous avons créée, nous utilisons la fonction registrer_post_type pour enregistrer le nouveau type de publication. Nous l’enregistrons avec un identifiant unique event qui signifie événement en anglais.

Par convention, j’utilise toujours l’anglais pour les identifiants. Ensuite dans les autres paramètres je spécifie le texte en français.

Voici un détail des paramètres passés à cette fonction dans cet exemple :

• labels : Ici on passe les différents noms pour notre nouveau type. Au pluriel, au singulier et pour tous les éléments. Ces textes seront utilisés dans l’administration de WordPress. Vous noterez qu’on affiche le texte avec la méthode __(), celle-ci permet d’enregistrer une traduction pour ce texte, si aucune traduction n’existe, le texte donné est utilisé.
• public : Indique si le type est public et vise à être utilisé dans l’administration et sur votre site. D’autres fonctions plus spécifiques peuvent être utilisées pour encore affiner cette option comme publicly_queryable ou exclude_from_search.
• has_archive : Indique si une page d’archive doit exister pour ce type de publication. Une page d’archive permet d’afficher la liste des publications de ce type dans une page spécifique.
• rewrite : Ici, on peut spécifier un autre nom pour le lien. Par défaut si on voulait accéder aux événements on taperait votresite.com/event (le nom du type créé), ici je précise que je veux plutôt utiliser events, donc votresite.com/events. À vous de voir le texte que vous voulez utiliser.
• supports : Spécifie les champs par défaut de WordPress qui sont supporter par ce type de publication. Dans notre cas, nous voulons pouvoir spécifier un titre pour la publication, gérer les révisions (ce qui gardera un historique des modifications) et l’attribut thumbnail qui permet d’utiliser le champ Image mise en avant. Il en existe d’autres, comme comments pour autoriser les commentaire ou author pour garder une trace de l’auteur de la publication.
• menu-icon : Ici on précise l’icône qu’on souhaite utiliser pour l’affichage dans l’administration. J’ai choisi l’icône de ticket que vous pouvez voir plus haut, mais n’hésitez pas à aller parcourir les icônes disponibles !
• publicly_queryable : Cet attribut, faux par défaut, permet de s’assurer que lors d’une requête (par exemple une recherche) depuis le site, le type de champ peut-être inclue dans la recherche.

Pour en savoir plus sur register_post_type, jetez un œil à la très bonne documentation de WordPress.

Si vous enregistrez votre fichier functions.php et que vous retournez dans votre administration, vous devriez voir apparaître votre nouveau type de publication dans le menu à gauche !

Si vous cliquez sur Ajouter, vous verrez qu’il sera possible de lui spécifier un titre et de lui donner une image mise en avant.

Nous allons maintenant utiliser ACF pour ajouter des champs à ce type de publication !

2. Créer un nouveau groupe de champs dans ACF

Laissons le code de côté pour un moment, nous allons maintenant créer notre groupe de champs à associer au type Événements que nous venons de créer.

Rendez-vous dans l’administration de WordPress sous ACF > Groupes de champs. Et là, cliquez sur Ajouter.

Avant de commencer la création de nos différents champs, récapitulons de quoi nous aurons besoin pour ce type de publication et ce que WordPress nous fournit déjà :

• Titre de l’événement : Nous avons ajouté le support de title dans notre méthode registrer_post_type, nous utiliserons donc le champ du titre de publication de WordPress natif pour ça.
• Date et heure de l’événement : Nous utiliserons un sélecteur de date jQuery pour se faire
• Type d’événement : Pour l’exemple, j’utiliserai une liste déroulante, mais il pourrait aussi s’agir d’un champ de texte
• Description : Nous aurions pu utiliser l’éditeur de WordPress par défaut en ajoutant editor dans l’attribut supports de register_post_type. Cela permettrait de construire le contenu avec WordPress ou un autre builder. Afin de garder le contrôle de la mise en forme et éviter que l’utilisateur fasse n’importe quoi (ça leur arrive ;)), nous allons plutôt utiliser une simple zone de texte pour cette information.
• Photo illustrative : Il serait possible de créer un champ image avec ACF pour avoir plus de contrôle (rendre le champ obligatoire par exemple), mais tant que nous pouvons utiliser les champs par défaut de WordPress, il n’y a pas de raison. Pour l’image, nous utiliserons donc l’image mise en avant, supportée par notre nouveau type de publication.

Nous créerons donc uniquement trois champs pour compléter notre nouveau type de publication. Pour commencer donnez un nom à votre groupe de champs, je l’ai nommé Événements, tout simplement.

Ensuite avant d’oublier, nous allons spécifier à ACF que ce groupe de champ doit s’afficher sur le type de publication Événements. Pour se faire sous Assigner ce groupe de champ, sélectionnez simplement Événement plutôt qu’Article dans le menu déroulant.

Attaquons la création des champs à proprement parler, en commençant par la date et l’heure de l’événement :

Voici mes commentaires au sujet de ce champ :

1. Nom du champ : Par convention, je nomme toujours mes champs en anglais, mais libre à vous de l’appeler date_heure si vous le souhaitez.
2. Type de champ : Le champ Date et heure se trouve sous l’onglet jQuery. Cela veut dire que la librairie jQuery (et plus spécifiquement jQuery UI) sera chargée pour afficher un sélecteur de date dynamique.
3. Requis : Les 3 champs que nous allons créer seront tous obligatoires, afin de ne pas permettre de publier d’événement avec des informations incomplètes.
4. Format de l’administration : Il s’agit de la façon dont le champ sera affiché lorsqu’on choisit une date depuis l’interface d’administration. Vous voyez que j’ai personnalisé l’affichage pour remplacer les / par des points, format de date standard en Suisse.
5. Format dans le modèle : Ici, cela vous indique sous quel format sera retournée la date quand vous l’affichez sur le site. J’ai appliqué le même format. Attention, la date n’est jamais retournée comme un objet date dans le code si vous affichez ce champ, il s’agira d’un champ de texte formaté selon vos besoins.
6. Attributs du conteneur : Ceci veut dire que ce champ prendra 50% de la largeur lorsque vous modifierez un événement. Le champ Type d’événement utilisera les 50 autres pour cent. Vous verrez plus loin le résultat.

Créons à présent notre deuxième champ permettant de choisir le type d’événement :

Mes commentaires sur ce champ :

1. Type de champ : J’ai choisi une liste déroulante pour vous présenter cette fonctionnalité, vous pouvez aussi privilégier un champ de texte, à vous de voir. La liste vous donne plus de contrôle sur la saisie.
2. Choix : Ici je suis resté simple en saisissant un simple texte, mais vous pourriez pousser les choses en créant pour chaque ligne une valeur et un texte en tapant le format valeur : texte. Par exemple pour un sélecteur de nombre de jours, on pourrait imaginer ce type de valeur : 1 : 1 jour, 2 : 2 jours, 3 : 3 jours. De cette manière vous pourrez gérer la valeur (le nombre) tout en affichant un texte représentatif.
3. Valeur par défaut : Ici vous pourriez ajouter une ou plusieurs valeurs par défaut. Si j’avais saisi Concert, par défaut ce champ sera déjà saisi. Vous pouvez en ajouter plusieurs si vous autorisez la sélection multiple plus bas dans Plusieurs valeurs possibles ?
4. Autoriser une valeur vide : Cette option permettrait au visiteur d’avoir une première option vide dans la liste. Si le champ est requis, il devrait choisir une option, mais il pourrait se contenter de choisir la première option vide.
5. Interface avancée : Cette option permet de créer une vue de sélection avancée avec un contrôle par Ajax, nous ne l’utiliserons pas ici.
6. Format dans le modèle : Ici vous pouvez gérer la manière dont l’information est retournée dans le code. En reprenant l’exemple de nos jours, si on choisit 1 jour et qu’ici on souhaite retourner la valeur, dans le code, on recevra la valeur 1. Si on souhaite retourner le texte, on recevra la valeur 1 jour et si on préfère avoir les deux, un tableau contenant la valeur et le contenu du texte. Dans notre cas, la valeur = le texte dont ça n’a pas d’importance.
7. Attributs du conteneur : Celui-ci prendra les 50 autres pour cent de la largeur.

Et le dernier champ de description :

Il s’agit du champ le plus simple, la plupart des champs sont plutôt logiques, voici mes commentaires :

1. Lignes : 8 par défaut, permet de gérer la hauteur du champ à l’affichage dans l’administration.
2. Nouvelles lignes : Cette option permet de gérer la façon dont sont générées les nouvelles lignes. Si on tape du texte dans le champ de la description et qu’on fait un saut de ligne, est-ce que celui-ci doit être créé sous la forme d’un simple saut de ligne <br> en HTML, est-ce qu’il doit être sous la forme d’un paragraphe, entouré de <p> (c’est le choix que j’ai fait ici) ou est-ce qu’il ne doit pas en tenir compte en ne faisant rien.
3. Attributs du conteneur : Ici je ne spécifie pas de largeur, tout simplement parce que je veux que la description prenne 100% de la taille, qui est la valeur par défaut.

Voilà, nos 3 champs obligatoires sont désormais créés. Pour terminer, nous allons encore personnaliser rapidement la façon dont ces champs s’affichent dans l’administration.

Par défaut, si on publie ce groupe de champ sans apporter d’autres modifications, voici comment ils s’afficheront dans la vue de gestion de nos événements :

Vous me direz que ce n’est pas mal du tout et plutôt propre avec la mise en page par défaut, non ? Et vous n’aurez pas tort, mais j’ai deux soucis avec ce visuel par défaut :

1. Le cadre, avec la possibilité d’afficher ou masquer les champs, ça ne colle pas, ces champs sont obligatoires et font partie intégrante de notre contenu. L’utilisateur ne doit pas pouvoir passer à côté ou avoir l’impression qu’il s’agit d’infos supplémentaires d’un plug-in quelconque.
2. Le contenu de la plupart des extensions s’affichera avant nos champs personnalisés, les reléguant tout en bas de la vue. Regardez ce qu’il se passe si Yoast SEO est installé sur votre site.

Une précision, les réglages que je vais appliquer sont propres à mes besoins et à mes préférences, libre à vous là encore d’expérimenter avec, de les modifier en fonction de l’importance de vos champs, etc.

Mais voici, dans notre cas, comment j’effectuerais ce réglage :

Et mes commentaires à ce sujet, pour ce que j’ai modifié :

• Style : On se débarrasse des contours et de l’aspect boîte de nos champs en les intégrant directement à la page.
• Position : Permets d’afficher les champs en priorité, juste après le titre, plutôt qu’ils s’affichent en toute fin de vue.
• Numéro d’ordre : Je ne l’ai pas modifié, mais sachez que si vous appliquez plusieurs groupes de champs à un même type de publication, vous pourrez forcer leur ordre d’affichage avec cette option.

Pour le résultat suivant, qui fonctionne parfaitement même avec Yoast SEO installé :

Les champs sont disponibles directement dans notre vue, sans fioriture, l’utilisateur ne peut pas passer à côté !

Une fois cela fait, on va saisir quelques événements pour le fun. Pour tester la suite, saisissez au moins 2 événements, de 2 types différents, avec et sans image mise en avant.

Une fois vos événements créés, avant de personnaliser leur affichage, allons jeter un oeil à quoi ils ressemblent actuellement. J’utilise pour cet exemple le thème twentytwenty par défaut de WordPress.

Voici à quoi ressemble un événement où j’ai ajouté une image mise en avant :

Évidemment, à part l’image et le titre, qui sont affichés par défaut dans le modèle de WordPress, pas grand-chose à se mettre sous la dent. WordPress gère le contenu comme un article, avec ces infos meta (auteur, date), mais tous les champs ACF sont ignorés.

Normal, le modèle par défaut de WordPress ne s’occupe pas d’afficher ce genre d’information. Alors nous allons le personnaliser !

3. Créer le modèle d’un événement

Si vous voulez en savoir plus sur la personnalisation des modèles d’un thème WordPress, je vous conseille mon article sur le sujet, nous réutiliserons d’ailleurs certains éléments pour cet exemple.

La première chose à faire et de donner à WordPress l’indication d’utiliser notre modèle pour afficher notre nouveau type de publication Événement.

Il faut savoir que par défaut, le fichier utilisé pour afficher un post (donc n’importe quel type de publication) est single.php ou éventuellement singular.php qui est utilisé pour gérer les pages en plus des articles.

Dans le cas du thème twentytwenty, il n’existe pas de fichier single.php, mais le fichier singular.php fait ce dont nous avons besoin. Lorsque je personnalise un thème, je réutilise en général le code de base du fichier que je vais personnaliser.

Si on jette un œil au code de singular.php au sein de twentytwenty voici à quoi ça ressemble :

<?php
/**
 * The template for displaying single posts and pages.
 *
 * @link https://developer.wordpress.org/themes/basics/template-hierarchy/
 *
 * @package WordPress
 * @subpackage Twenty_Twenty
 * @since Twenty Twenty 1.0
 */

get_header();
?>

<main id="site-content" role="main">

   <?php

   if ( have_posts() ) {

      while ( have_posts() ) {
         the_post();

         get_template_part( 'template-parts/content', get_post_type() );
      }
   }

   ?>

</main><!-- #site-content -->

<?php get_template_part( 'template-parts/footer-menus-widgets' ); ?>

<?php get_footer(); ?>

Très simple non ? Oui, puisque depuis le thème twentynineteen, les thèmes WordPress de base fonctionnent activement sur la séparation des modèles, donc ici il utiliser un autre modèle pour afficher le contenu de l’article

On peut voir l’appel à la fonction get_template_part qui va chercher le contenu du fichier template-parts/content suivi du slug unique du type d’article. En gros, si on est dans un type event, WordPress tentera d’aller chercher le fichier de modèle content-event.php dans le dossier template-parts.

Et s’il ne le trouve pas, il se contentera d’afficher le fichier content.php. Plutôt efficace !

En fonction du thème que vous utilisez cependant, vous serez peut-être obligé de créer un nouveau fichier single-event.php qui contiendra le code du fichier single.php ou singular.php, la boucle des événements, l’affichage de l’événement, etc. tout ça dans un seul fichier.

Et vous pouvez même le faire avec le thème twentytwenty. En créant un fichier single-event.php celui-ci aura préséance sur le modèle du thème parent.

Mais dans notre cas, le plus simple est de reprendre le contenu du fichier content.php qui se trouve dans le thème parent, sous template-parts. Et de créer dans votre thème enfant le fichier suivant :

[thème-enfant]/template-parts/content-event.php

En remplaçant son contenu par celui de content.php. C’est ce contenu qui sera chargé par défaut dans les articles de type event et vous n’avez pas à vous soucier du code du fichier qui s’occupe de charger ce contenu.

Vous verrez en jetant un oeil dans le fichier content.php que celui-ci fait appel à l’en-tête de l’article se trouvant dans un autre modèle avec par exemple get_template_part( 'template-parts/entry-header' ).

Vous pouvez recréer des modèles spécifiques pour l’en-tête d’événement, le créer dans votre thème enfant sous template-parts avec le nom entry-header-event.php si vous le souhaitez, puis la charger en faisant get_template_part( 'template-parts/entry-header' , 'event' ).

De mon côté, voici comment j’ai modifié le fichier content-event.php.

Je ne charge pas d’autres modèles, tout se passe dans cette vue. Pour être au plus juste, j’ai repris le contenu des fichiers chargés initialement dans content.php, comme justement entry-header.php.

<article <?php post_class(); ?> id="post-<?php the_ID(); ?>">

   <!-- En-tête de l'événement -->
   <header class="entry-header has-text-align-center<?php echo esc_attr( $entry_header_classes ); ?>">

      <div class="entry-header-inner section-inner medium">

         <!-- Titre de l'événement -->
         <h1 class="entry-title"><?php the_title(); ?></h1>

         <!-- Information de l'événement -->
         <div class="post-meta-wrapper post-meta-single post-meta-single-top">
            <ul class="post-meta">
               <li class="meta-wrapper">
                  <!-- Date et heure -->
                  <span class="meta-text">Date : <?php echo(get_field("date_time")); ?></span>
               </li>
               <li class="meta-wrapper">
                  <!-- Type -->                  
                  <span class="meta-text">Type : <?php echo(get_field("type")); ?></span>
               </li>               
            </ul>
         </div>

      </div>
   </header>

   <!-- Image de l'événement -->
   <?php
      
      if ( has_post_thumbnail() ) {
   ?>

   <figure class="featured-media">
      <div class="featured-media-inner section-inner">
         <?php the_post_thumbnail(); ?>
      </div>
   </figure>

   <?php
      }
   ?>

   <!-- Contenu de l'événement -->
   <div class="post-inner thin">
      <div class="entry-content">
         <?php
            // Afiche le contenu de la description
            echo(get_field("description"));
         ?>
      </div>
   </div>
</article>

Il n’y pas grand-chose à dire, la structure et les classes sont reprises de ce qui existe dans twentytwenty, pour m’assurer de conserver les styles. Ensuite j’utilise 2 méthodes spécifiques :

• get_field : Cette méthode est spécifique à ACF et permet de récupérer le champ ACF donné en paramètre. Ici je récupère date_time et type afin de les afficher dans les données meta de mon événement, sous le titre. Je fais du même plus bas dans le contenu en affichant la description avec echo(get_field("description"))
• the_post_thumbnail : Cette méthode WordPress génère et affiche automatiquement l’image mise en avant si elle existe, rien si elle n’existe pas. Cependant pour éviter que le conteneur de l’image n’ajoute un espace indésiré à l’affichage, je n’affiche l’image que s’il en existe une pour l’événement. Si elle est affichée, elle est automatiquement complétée avec ses différents attributs (tailles, texte alternatif, etc.).

Voici le résultat, très simple, que j’obtiens avec cette modification, pour mon événement avec une image mise en avant :

Les différents éléments de l’événement sont ensuite repris ici, avec notre date, le type d’événement et la description sous l’image si celle-ci existe.

5. Afficher la liste des événements

Vous pouvez donc afficher votre événement si un visiteur clique dessus pour l’afficher, mais comment gérer l’affichage de la liste des événements ? Pour voir à quoi ressemble cet affichage, rendez-vous sur :

http://[votre-site]/events

Cette vue représente la page d’archive de vos événements et elle vous en affichera la liste. Et vous verrez alors que ça fonctionne plutôt bien ! Avec la liste de vos événements affichés à la suite.

Seulement actuellement, le contenu de l’événement est affiché de la même manière si on est sur la liste des événements, que si on se trouve sur l’événement en question.

Dans cette liste, imaginons par exemple que vous ne souhaitiez pas afficher la description, diminuer la taille du titre et ajouter un lien vers l’événement en question.

En gros pour un résultat de ce genre :

Il suffit en fait de quelques conditions pour modifier cet affichage.

Comme vous pouvez récupérer le contexte dans lequel vous vous trouvez en demandant à WordPress dans quel type de page (article seul, recherche, archive, etc.) le modèle est affiché, rien de bien compliqué.

Voici comment vous devrez personnaliser votre fichier content-event.php. Pour un affichage de ce type, tout en conservant les styles du thème :

<article <?php post_class(); ?> id="post-<?php the_ID(); ?>">

   <!-- En-tête de l'événement -->
   <header class="entry-header has-text-align-center<?php echo esc_attr( $entry_header_classes ); ?>">

      <div class="entry-header-inner section-inner medium">

         <!-- Titre de l'événement -->
         <?php

            if ( is_singular() ) {
               the_title( '<h1 class="entry-title">', '</h1>' );
            } else {
               the_title( '<h2 class="entry-title heading-size-1"><a href="' . esc_url( get_permalink() ) . '">', '</a></h2>' );
            }

         ?>

         <!-- Information de l'événement -->
         <div class="post-meta-wrapper post-meta-single post-meta-single-top">
            <ul class="post-meta">
               <li class="meta-wrapper">
                  <!-- Date et heure -->
                  <span class="meta-text">Date : <?php echo(get_field("date_time")); ?></span>
               </li>
               <li class="meta-wrapper">
                  <!-- Type -->                  
                  <span class="meta-text">Type : <?php echo(get_field("type")); ?></span>
               </li>               
            </ul>
         </div>

      </div>
   </header>

   <!-- Image de l'événement -->
   <?php
      
      if ( has_post_thumbnail() ) {
   ?>

   <figure class="featured-media">
      <div class="featured-media-inner section-inner">
         <?php the_post_thumbnail(); ?>
      </div>
   </figure>

   <?php
      }
   ?>

   <!-- Contenu de l'événement -->
   <div class="post-inner thin">
      <div class="entry-content">
         <?php
            if ( is_search() || ! is_singular()) {
               echo( '<p class="has-text-align-center"><a class="button" href="' . get_permalink() . '">' . __( 'Afficher l\'événement', 'twentytwentychild' ) . '</a></p>' );
            } else {
               echo(get_field("description"));
            }
         ?>
      </div>
   </div>
</article>

Vous pouvez voir que j’ai ajouté 2 conditions, vérifiant s’il s’agit d’une page de recherche ou d’une liste d’articles (différent de is_singular, qui veut dire seul) :

• La première à l’affichage du titre, sur lequel j’ajoute le lien vers l’événement et que j’affiche en <h2> au lieu de <h1>
• La seconde permet d’afficher un bouton Afficher l’événement tout en bas. J’ai utilisé les classes déjà définies dans le thème comme has-text-align-center pour aligner au centre et button pour afficher le lien sous forme de bouton. Et j’utilise la méthode __() afin d’afficher un texte qui pourra ensuite être traduit dans l’administration au besoin.

Et si vous effectuez une recherche, l’événement sera également affiché sous cette forme.

Les possibilités sont nombreuses, je tiens à préciser que pour des questions de simplicité, je ne touche pas au CSS et je personnalise le visuel au minimum, le but ici est surtout de montrer que les méthodes de WordPress et les modèles personnalisés, associés à ACF peuvent vous permettre d’aller très loin.

Quid des builder types Divi ou Elementor ?

Que ce soit Divi ou Elementor, ils proposent désormais tous les deux ce qu’on appelle un thème Builder, qui vous permet de gérer des modèles spécifiques en fonction des types d’articles.

Pour information, pour ajouter des champs dynamiques depuis ACF, vous aurez besoin de la version Pro d’Elementor, la version gratuite n’offre pas cette fonctionnalité. Divi quant à lui est payant de toute manière.

Divi

Je parle de Divi dans mon article précédent sur ACF ou je présente les fonctionnalités qui permettent de gérer des modèles d’articles spécifiques pour un type d’article donné.

Commencerez par créer un modèle spécifique au type Événement depuis le Thème Builder :

Ensuite, dans ce modèle, il est possible de gérer l’affichage des champs d’ACF et de les ajouter. À chaque fois que vous voyez s’afficher la petite icône de base de données, vous pourrez utiliser des valeurs présentes dans les champs personnalisés.

Vous pourrez y ajouter du contenu avant et après (comme ici une balise de paragraphe) mais vous ne pourrez pas cumuler les champs pour les afficher à la suite.

Autre chose, si vous êtes dans un article et que le champ des événements n’est pas disponible, Divi vous le proposera quand même, même s’il n’affichera rien.

Divi ne connaît pas le te contexte et vous permet d’ajouter n’importe quel champ, n’import où. S’il n’existe pas, il ne l’affichera simplement pas.

Pour aller plus loin avec ça, cumuler Divi et un peu plus de liberté, vous pouvez utiliser les shortcodes d’ACF ou un shortcode personnalisé pour formater l’affichage de vos champs comme vous le souhaitez.

Jetez un œil à mon article précédent pour plus d’infos.

[affiliate_cta subtitle= »Vous êtes intéressé par Divi ? » title= »Un gros rabais sur Divi 4.0 ! » content= »Divi c’est LE thème WordPress Premium par excellence, s’il vous intéresse, profitez d’un rabais de 20% à l’achat de Divi 4.0 en suivant ce lien ! » button_caption= »-20% sur votre commande de Divi 4.0″ product= »divi » url= »/urls/divi »]

Elementor

Rendez-vous dans les Modèles d’Elementor, sous Theme Builder, puis sous Single pour gérer les pages d’articles. Ensuite en faisant Ajouter un E-Single vous pourrez créer votre modèle d’événement.

Une fois que vous éditez votre modèle, vous pourrez gérer l’affichage de champs personnalisés à chaque fois que l’icône de base de données est disponible. Voici comment faire pour un champ de texte :

Il faut commencer par choisir le type de champ ACF Field, puis choisir le champ en question dans la liste. Dernière chose, dans les Réglages avancés du champ vous pourrez ajouter un contenu à afficher avant ou après (ici une balise de paragraphe) ainsi qu’un texte par défaut si le champ est vide.

Comme pour Divi, vous ne pourrez pas cumuler les champs et les afficher à la suite au sein d’un même texte, mais vous pouvez également utiliser les shortcodes d’ACF ou créer votre propre shortcode comme je l’explique dans mon article précédent.