Modelli di archivio personalizzati: una breve guida

Ogni volta che lavori con i modelli di archivio in WordPress, i post sono generalmente elencati per data in ordine decrescente. Cioè, i post più recenti sono elencati in alto, e poi si va da lì.

Ultimamente, ho lavorato su alcuni progetti che si integrano con API di terze parti. Queste API restituiscono date, a volte due date, una data di inizio e una data di fine, per un determinato evento e i clienti desiderano utilizzare tali informazioni per elencare i post anziché la data del post. Cioè, vogliono modelli di archivio personalizzati.

Non è troppo difficile farlo, ma prima di farlo, penso che sia importante fornire alcune informazioni di base su come è costruito il progetto, quindi c’è un po’ più di contesto sul perché, ad esempio, è necessaria una query personalizzata e perché potresti o potresti non è necessario esaminare pre_get_posts.

Inizierò con un TL; DR prima, però. In questo modo, puoi farti un’idea prima di leggere tutto.

Modelli di archivio personalizzati

Quindi il TL; DR dietro l’intera cosa è questo:

• le informazioni sulla data fornite dall’API di terze parti sono conservate nella tabella dei metadati post,
• la chiave è la data di inizio e il valore è la data effettiva,
• Ordino il contenuto in ordine decrescente e in base al meta valore.

L’impaginazione può essere un po’ un problema e se usi un tipo di post personalizzato, avrai bisogno di alcuni parametri extra, ma c’è l’idea generale.

Ora per l’intera configurazione.

Tipi di post personalizzati

Quando si tratta di interfacciarsi con API di terze parti, sono un grande fan dei tipi di post personalizzati perché tendo a pensarli come un ibrido tra modelli e viste.

• Il componente del modello include tutto ciò che è tangenzialmente correlato e può essere scritto nel database. Ciò significa qualsiasi informazione sulla tassonomia o metadati dei post.
• Il componente di visualizzazione è generalmente tutto ciò che entra nel modello in grado di sfruttare eventuali tag di modello preesistenti, ovvero tutto ciò che potrebbe essere necessario creare che legga anche le informazioni dal database.

Per questo post, userò acme-event come tipo di post personalizzato.

Pubblica metadati

Ho impostato le date nei metadati del post piuttosto che nel post stesso perché se succede qualcosa in futuro e i dati sono impostati sul record del post stesso, WordPress lo tratterà come un post programmato che non è pubblicato .

Invece, preferirei pubblicare il post e quindi modificare il modo in cui i metadati vengono visualizzati nel modello.

Impaginazione

WordPress fa una sottile distinzione con l’impaginazione nella sua base di codice. Ovvero, la variabile di query per i siti senza una home page statica utilizza paged e il caso opposto utilizza page.

Questo è importante quando stai costruendo gli argomenti per la query a cui arriverò momentaneamente.

Solo pagine di archivio

Ricorda che ogni volta che stai introducendo l’impaginazione, vuoi cambiare la query solo ogni volta che ti trovi nella pagina di archivio effettiva.

Ciò significa che non ti interessano i casi quando sei nell’area amministrativa di WordPress e non vuoi modificare la query per archivi di tipo post non personalizzato. A tal fine, assicurati di impostare correttamente la variabile di query nel callback pre_get_posts.

Nota che posso mostrare una funzione su come farlo, ma a causa del modo in cui scriviamo il codice in WordPress, ovvero alcuni scrivono codice procedurale, altri scrivono codice orientato agli oggetti, lo visualizzerò semplicemente nel codice procedurale.

Unendo tutto

Per prima cosa, costruirò la query:

<?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
]);

Nota che nel codice sopra c’è un argomento per paged. Parlerò del codice per questo momentaneamente.

Quindi il modello includerà tutte le informazioni che scegli di visualizzare. Ho scelto di non condividere il codice per il mio modello in questo post perché è irrilevante per l’idea più ampia a portata di mano.

Inoltre, hai tutto il necessario per visualizzare il contenuto.

Successivamente, imposterò l’impaginazione. Innanzitutto, devo farlo usando l’hook pre_get_posts per assicurarmi che sia impostata la variabile di query corretta :

<?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);
    }
}

Quindi implementerò l’impaginazione utilizzando la query personalizzata:

<?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>

E dopo, ripristinerò la variabile $post globale usando wp_reset_postdata() nel caso in cui sia necessario utilizzare qualsiasi cosa del post originale.

<?php wp_reset_postdata(); ?>

Questo è generalmente considerato una buona pulizia ogni volta che si utilizza una query personalizzata, comunque.

link utili

Di seguito è riportato un elenco di funzioni, pagine e riferimenti che potresti trovare utili in relazione al codice sopra o a qualsiasi lavoro futuro che potresti svolgere.

• WP_Query
• Impaginazione
• 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
• Il codice completo in questo post.

Se lavori con WordPress da molto tempo, alcuni di questi potrebbero sembrare ridondanti. In altri casi, potrebbe sembrare nuovo o potrebbe far luce su aree delle API di WordPress che non sapevi esistessero (almeno per me era così).

Perché preoccuparsi di tutto questo?

Questo può sembrare un post lungo per un compito apparentemente semplice, ma le informazioni sono un po’ sparse in tutto il Web in quanto si riferiscono a fare qualcosa del genere.

Quindi ho voluto provare a riunire il tutto con spiegazioni, codice di esempio e collegamenti a pagine che potrebbero essere di interesse a seconda di come viene eseguita l’implementazione.

Dopotutto, molti di noi stanno utilizzando WordPress al di là della gestione dei contenuti di base a questo punto, ma ciò non significa che non dovremmo sfruttare le sue funzioni e API integrate quando possibile.