Modèles d’archives personnalisés : un petit guide

Chaque fois que vous travaillez avec des modèles d’archives dans WordPress, les publications sont généralement répertoriées par date dans l’ordre décroissant. C’est-à-dire que les messages les plus récents sont répertoriés en haut, puis cela part de là.

Dernièrement, j’ai travaillé sur quelques projets qui s’intègrent à des API tierces. Ces API renvoient des dates – parfois deux dates, une date de début et une date de fin – pour un événement donné et les clients souhaitent utiliser ces informations pour répertorier les publications plutôt que la date de la publication. Autrement dit, ils veulent des modèles d’archives personnalisés.

Ce n’est pas trop difficile à faire, mais avant de le faire, je pense qu’il est important de donner quelques informations générales sur la façon dont le projet est construit afin qu’il y ait un peu plus de contexte autour de pourquoi, disons, une requête personnalisée est nécessaire et pourquoi vous pouvez ou pouvez pas besoin de se pencher sur pre_get_posts.

Je vais commencer par un TL; DR d’abord, cependant. De cette façon, vous pouvez vous faire une idée avant de tout lire.

Modèles d’archives personnalisés

Donc, le TL; DR derrière tout cela est ceci :

• les informations de date fournies par l’API tierce sont conservées dans la table de métadonnées post,
• la clé est la date de début et la valeur est la date réelle,
• Je commande le contenu par ordre décroissant et par la méta-valeur.

La pagination peut être un peu problématique, et si vous utilisez un type de publication personnalisé, vous aurez besoin de paramètres supplémentaires, mais il y a l’idée générale.

Passons maintenant à l’ensemble du montage.

Types de publication personnalisés

En ce qui concerne l’interface avec des API tierces, je suis un grand fan des types de publication personnalisés, car j’ai tendance à les considérer comme un hybride entre les modèles et les vues.

• Le composant de modèle inclut tout ce qui est tangentiellement lié et peut être écrit dans la base de données. Cela signifie toute information de taxonomie ou publication de métadonnées.
• Le composant de vue est généralement tout ce qui entre dans le modèle et qui peut exploiter les balises de modèle préexistantes, c’est-à-dire tout ce qui peut devoir être créé et qui lit également les informations de la base de données.

Pour ce post, je vais utiliser acme-event comme type de post personnalisé.

Publier les métadonnées

J’ai défini les dates dans les métadonnées de la publication plutôt que sur la publication elle-même, car si quelque chose doit se produire dans le futur et que les données sont définies sur l’enregistrement de la publication elle-même, WordPress la traitera comme une publication planifiée non publiée. .

Au lieu de cela, je préférerais que le message soit publié, puis modifier la façon dont les métadonnées sont affichées dans le modèle.

Pagination

WordPress fait une distinction subtile avec la pagination dans sa base de code. Autrement dit, la variable de requête pour les sites sans page d’accueil statique utilise paged et le cas contraire utilise page.

C’est important lorsque vous construisez les arguments de la requête que j’aborderai dans un instant.

Archiver uniquement les pages

N’oubliez pas que chaque fois que vous introduisez la pagination, vous ne souhaitez modifier la requête que lorsque vous êtes sur la page d’archives réelle.

Cela signifie que vous ne vous souciez pas des cas où vous vous trouvez dans la zone administrative de WordPress et que vous ne souhaitez pas modifier la requête pour les archives de type publication non personnalisées. À cette fin, vous devez vous assurer que vous définissez correctement la variable de requête dans le rappel pre_get_posts.

Notez que je peux montrer une fonction pour savoir comment faire cela, mais en raison de la façon dont nous écrivons du code dans WordPress – c’est-à-dire que certains écrivent du code procédural, d’autres écrivent du code orienté objet – je l’afficherai simplement dans le code procédural.

Rassembler le tout

Tout d’abord, je vais créer la requête :

<?php

$eventQuery = new WP_Query([
    'post_type' => 'acme-events',
    'post_status' => 'publish',
    'orderby' => 'meta_value',
    'order' => 'desc',
    'meta_key' => 'acme-event-start-date-time',
    'posts_per_archive_page' => 5,
    'paged' => get_query_var('paged')? get_query_var('paged'): 1
]);

Notez que dans le code ci-dessus, il y a un argument pour paged. Je vais parler du code pour cela momentanément.

Ensuite, le modèle inclura toutes les informations que vous choisissez d’afficher. Je choisis de ne pas partager le code de mon modèle dans cet article car il n’est pas pertinent pour l’idée plus large à portée de main.

De plus, vous avez tout ce dont vous avez besoin pour afficher le contenu.

Ensuite, je vais définir la pagination. Tout d’abord, je dois le faire en utilisant le crochet pre_get_posts pour m’assurer que la variable de requête appropriée est définie :

<?php

add_action('pre_get_posts', 'setCustomQueryVariable');
public function setCustomQueryVariable($query)
{
    if (is_admin() || !is_archive()) {
        return;
    }

    if ($query->is_archive('acme-events')) {
        set_query_var('posts_per_page', 5);
    }
}

Ensuite, je vais implémenter la pagination à l’aide de la requête personnalisée :

<?php

<a class="next page-numbers" href="<?php echo esc_attr(get_next_posts_page_link($eventQuery->max_num_pages)); ?>">
    Next Page
</a>

<a class="prev page-numbers" href="<?php echo esc_attr(get_previous_posts_page_link()); ?>">
    Previous Page
</a>

Et après cela, je réinitialiserai la variable globale $ post en utilisant wp_reset_postdata() juste au cas où quelque chose de la publication d’origine devrait être utilisé.

<?php wp_reset_postdata(); ?>

Ceci est généralement considéré comme un bon entretien chaque fois que vous utilisez une requête personnalisée, de toute façon.

Liens utiles

Vous trouverez ci-dessous une liste de fonctions, de pages et de références qui pourraient vous être utiles en ce qui concerne le code ci-dessus ou tout travail futur que vous pourriez effectuer.

• WP_Query
• Pagination
• pre_get_posts
• get_query_var
• set_query_var
• get_next_posts_page_link
• get_previous_posts_page_link
• update_post_meta
• wp_reset_postdata
• Le code complet dans ce post.

Si vous travaillez avec WordPress depuis longtemps, certains d’entre eux peuvent sembler redondants. Dans d’autres cas, cela peut sembler nouveau, ou cela peut éclairer des domaines des API WordPress dont vous ne saviez pas qu’ils existaient (du moins c’était le cas pour moi).

Pourquoi s’embêter avec tout ça ?

Cela peut sembler être un long message pour une tâche apparemment simple, mais les informations sont un peu dispersées sur le Web en ce qui concerne la réalisation de quelque chose comme ça.

J’ai donc voulu essayer de rassembler le tout avec des explications, des exemples de code et des liens vers des pages qui peuvent être intéressantes en fonction de la manière dont la mise en œuvre est effectuée.

Après tout, beaucoup d’entre nous utilisent WordPress au-delà de la gestion de contenu de base à ce stade, mais cela ne signifie pas que nous ne devrions pas tirer parti de ses fonctions et API intégrées lorsque cela est possible.