it-swarm.dev

L'impaginazione restituisce 404 dopo la pagina 20

Ho ottenuto un ciclo di paging che richiama 4 post per pagina dal tipo di post personalizzato. Funziona alla grande, con l'unico svantaggio che la paginazione non passerà oltre page/20 dopo che sarà 404, e posts_nav_link non mostrerà affatto la prossima freccia. Come le pagine non ci sono.

In totale ci sono 119 post pubblicati nel tipo di post personalizzato. Se cambio posts_per_page, diciamo 6, ottengo l'accesso a più post dalla fine, ma si ferma anche su page/20.

Sul sito di produzione l'impaginazione si ferma a 21, immagino perché il database live ha più voci.

Ho ottenuto l'impostazione "Mostra pagine blog al massimo" impostata su 6.

Ecco il ciclo che sto usando:

<?php
$paged = get_query_var('paged') ? get_query_var('paged') : 1;
$args  = array(
    'posts_per_page' => 4,
    'orderby'        => 'modified',
    'post_type'      => "projekte",
    'paged'          => $paged
);
$custom_query = new WP_Query($args);
$c = 0;
while($custom_query->have_posts()) :
    $custom_query->the_post();
    ?>
    <article>...</article>
    <?php
endwhile;
wp_reset_postdata(); // reset the query
?>

Ho esaminato functions.php un milione di volte cercando un filtro get_pre_posts limitante, ma non c'è nulla che possa vedere.

Ho anche ottenuto una configurazione del registro degli errori e non viene restituito nulla, l'ho provato che funziona.

Eventuali suggerimenti?

4
any_h

Quello che stai vivendo è del tutto normale e atteso. Questo è uno dei motivi principali su cui mi aggrappo sempre a questo punto, mai usare query personalizzate per sostituire la query principale sulla home page o qualsiasi tipo di pagina di archivio. Risolvono un problema ma ne creano molti altri nuovi

Vediamo cosa hai e perché ottieni questi risultati:

BASE

Sebbene non venga visualizzato l'output nella pagina di archivio, la query principale viene eseguita su every caricamento della pagina e restituisce una serie di post indipendentemente. La rimozione del ciclo non interrompe l'esecuzione della query principale. Il ciclo mostra solo ciò che viene recuperato dalla query principale. Quindi, cosa sta succedendo, stai recuperando due serie di post per pagina se sostituisci il ciclo predefinito con uno personalizzato. I post recuperati dalla query principale e i post recuperati dalla query personalizzata. Se vuoi testare questo, aggiungi la seguente riga di codice al di fuori del loop nella tua pagina di archivio all'interno dei tag php

?><pre><?php var_dump( $wp_query->posts ); ?></pre><?php

Questo produrrà l'array di post recuperati dalla query principale su quella specifica pagina

Questo rende le query personalizzate molto inefficienti quando sostituisce la query principale. È come sostituire un pneumatico gonfiato che è in punta di forma con un pneumatico forato e consumato.

IL TUO SCENARIO

Hai il seguente scenario

  • 119 post dal tuo tipo di post personalizzato

  • L'opzione Post per pagina impostata in admin è 6

  • La query personalizzata è impostata per recuperare 4 post per pagina

LA MATH

La tua query principale restituirà 20 pagine che puoi testare con echo $wp_query->max_num_pages;. La matematica è facile, hai 119 post, che puoi anche verificare con echo $wp_query->found_posts;, i post per pagina sono impostati su 6 in admin, quindi il limite di 119/6 = 20

Per quanto riguarda la query personalizzata, è possibile accedere alle stesse informazioni di cui sopra cambiando $wp_query a $custom_query. Vedrai che hai ancora 119 post, ma avrai 30 pagine a causa del fatto che i post per pagina ora sono impostati su 4. Il limite per 119/4 = 30

404 A PAGINA 21

Ogni volta che non ci sono post da visualizzare dalla query principale, viene attivato un 404, e questo è ciò che stai vedendo. Ci sono abbastanza post per riempire 20 pagine, non 21 o più. Quindi, quando vai a pagina 21, la query principale 404 è semplicemente perché non ci sono più post da visualizzare, indipendentemente dal fatto che tu abbia ancora molto da visualizzare dalla tua query personalizzata.

Ho visto post in cui la gente dice che la soluzione è semplice, basta cambiare la quantità di post per pagina nella pagina di amministrazione in modo che corrisponda a quella della tua query personalizzata. Non farlo mai . Sì, risolve il problema, ma sconfigge il vero problema qui che non si dovrebbe sostituire la query principale con una personalizzata. E BTW, la vera soluzione al problema è abbastanza semplice, pulita ed è il metodo corretto per ottenere ciò che ti serve

PERCHÉ LA QUERY PERSONALIZZATA

Hai deciso di andare con una query personalizzata a causa di due cose

  • Diverse quantità di post per pagina nella pagina di archiviazione del tipo di messaggio personalizzato che il resto del sito

  • I post sono ordinati per data di modifica e non per data di post predefinita

Come puoi vedere, hai risolto due problemi con la tua query personalizzata ma hai creato altri problemi

LA SOLUZIONE

Questo è il metodo corretto e semplice per risolvere il tuo problema. Utilizzare pre_get_posts per modificare la query principale prima che venga eseguita. pre_get_posts altera di conseguenza le variabili di query che vengono utilizzate per calcolare la query SQL per la specifica richiesta di pagina.

Devi fare due cose qui, il primo sarebbe rimuovere la tua query personalizzata sulla tua pagina di archivio e sostituirla con il ciclo predefinito. Dopo averlo fatto, vedrai 6 post per pagina ordinati per data di pubblicazione, come dovrebbe essere per impostazione predefinita.

Ora apri functions.php e usa pre_get_posts per correggere la quantità di messaggi per pagina e ordinamento

add_action( 'pre_get_posts', function ( $q ) 
{
    if(    !is_admin() 
        && $q->is_main_query() 
        && $q->is_post_type_archive( 'projekte' ) 
    ) {
        $q->set( 'posts_per_page', 4          );
        $q->set( 'orderby',        'modified' );
    }
});

Ora dovresti vedere 4 post per pagina ordinati per data di modifica, paginati correttamente nella pagina di archivio del tipo di messaggio personalizzato projekte

LETTURA EXTRA

Dovresti anche leggere il post seguente che ho fatto su un problema simile qualche tempo fa, e tutti i post che ho collegato a quel post specifico

MODIFICARE

Per quelli bloccati con le versioni php di dinosauri che non supportano le chiusure, ecco la versione fallback dell'azione pre_get_posts

add_action( 'pre_get_posts', 'wpse176347_pre_get_posts' );
function wpse176347_pre_get_posts( $q ) 
{
    if(    !is_admin() 
        && $q->is_main_query() 
        && $q->is_post_type_archive( 'projekte' ) 
    ) {
        $q->set( 'posts_per_page', 4          );
        $q->set( 'orderby',        'modified' );
    }
}
18
Pieter Goosen