Tipo di post personalizzato - elenco post - schermo bianco della morte

sto ricevendo uno strano errore: schermata bianca nell'elenco dei post
per un tipo di post personalizzato specifico (solo per quello)

• provato a disattivare tutti i plugin
• provato a verificare l'errore (debugging = true)

Ancora niente
la pagina non echeggia nulla ... (niente anche nella fonte)

Sto parlando di un tale URL nell'amministratore:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Ecco la parte register_post_type che sto usando:

function register_submodelcpt() {
    $labels = array(
        'name'                  => __('Sub Models', THEME_NAME),
        'singular_name'         => __('Sub Models', THEME_NAME),
        'add_new'               => __('New Model', THEME_NAME),
        'add_new_item'          => __('Add new Model', THEME_NAME),
        'edit_item'             => __('Edit Model', THEME_NAME),
        'new_item'              => __('New Model', THEME_NAME),
        'all_items'             => __('All Sub Models', THEME_NAME),
        'view_item'             => __('Watch Model', THEME_NAME),
        'search_items'          => __('Search Models', THEME_NAME),
        'not_found'             =>  __('No Models found', THEME_NAME),
        'not_found_in_trash'    => __('No Models found in trash', THEME_NAME), 
        'parent_item_colon'     => '',
        'menu_name'             => __('Sub Models', THEME_NAME),

    );

    $args = array(
        'labels'                => $labels,
        'public'                => true,
        'publicly_queryable'    => true,
        'show_ui'               => true, 
        'show_in_menu'          => true, 
        'query_var'             => true,
        'rewrite'               => array('slug' => 'submodels'),
        'capability_type'       => 'post',
        'has_archive'           => true, 
        'hierarchical'          => true,
        'menu_position'         => 5,
        'menu_icon'             => get_stylesheet_directory_uri().'/images/cpt/subcars.png',            
        'supports'              => array('title', 'thumbnail', 'revisions', 'page-attributes')
    ); 
    register_post_type('submodelscpt',$args);
}
add_action('init', 'register_submodelcpt');

Qualcuno ha riscontrato un tale problema?
riesci a pensare a una ragione per cui ciò potrebbe accadere?

Un'altra cosa strana
quando cambio questo:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

A questo:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt&orderby=date&order=desc

L'elenco dei post viene caricato correttamente ...

Questo per estendere la tua risposta:

Sembra che quando "gerarchico" è impostato su true, ogni post si comporta come una pagina. Sto citando qui quindi non capisco davvero perché sia ​​importante, ma cambiando questa riga rimuovi il problema.

Ecco cosa dice il codice sul hierarchicalparametro

gerarchica

(booleano) (opzionale) Indica se il tipo di post è gerarchico (ad es. pagina). Consente di specificare Parent. Il parametro "supports" deve contenere "attributi di pagina" per mostrare la casella di selezione padre nella pagina dell'editor.

Predefinito: falso

Nota:  questo parametro è stato pianificato per Pages. Fai attenzione, quando lo scegli per il tuo tipo di post personalizzato - se hai intenzione di avere molte voci (diciamo - oltre 100), ti imbatterai in un problema di memoria. Con questo parametro impostato su true WordPress recupererà tutte le voci di quel particolare tipo di post, insieme a tutti i metadati, su ogni pagina di amministrazione caricata per il tuo tipo di post.

Quando un tipo di post personalizzato è impostato come gerarchico, il suo comportamento sarà lo stesso del tipo di post in build page. Come le pagine, Wordpress tenta di creare un albero per visualizzare l'albero gerarchico corretto con relazioni padre-figlio nel back-end. Come avrai notato, le pagine non sono ordinate per data nel back-end, ma in base a questa relazione padre-figlio. Questo comportamento si può facilmente vedere quando si visita la Pagepagina nel back-end.

Questa operazione è molto costosa in quanto Wordpress deve ottenere ogni pagina (o post da un tipo di post gerarchico) su ogni caricamento di pagina e quindi cercare le pagine padre e figlio di quella pagina / post specifica per creare un albero corretto per quella pagina / post specifico . Se hai un gran numero di pagine o post nel tuo tipo di post personalizzato gerarchico, la query diventa semplicemente grande e supera i limiti di memoria o il timeout, il che porta a un errore fatale, quindi il WSOD.

I tipi di post non gerarchici come il tipo di post build in postnon hanno una gerarchia tale che i post di tipo post non gerarchici non possono avere post figlio. Poiché non è necessario creare un albero delle relazioni padre-figlio (per ovvie ragioni), Wordpress esegue semplicemente una query di 20 ( IIRC ) post per pagina ordinati per data nel back-end e li visualizza in contrasto con i post di tipo gerarchico in cui Wordpress deve eseguire una query su tutti i post contemporaneamente, creare un albero e quindi visualizzare solo una quantità x su post raggruppati in base alla relazione padre-figlio. È possibile verificare questo comportamento nella Postpagina nel back-end

Quindi l'impostazione di un tipo di post personalizzato su gerarchico dice a Wordpress che dovrebbe creare un elenco / albero di post raggruppati in base alla loro relazione padre-figlio e restituire quei post in quella configurazione. Impostando un tipo di post personalizzato su non gerarchico, stai dicendo a Wordpress di saltare l'intera cosa della relazione e di restituire solo una quantità x di post per pagina ordinati per data di post

Spero che questo abbia un po 'più senso per te perché dovresti evitare di rendere gerarchici i tipi di post personalizzati e perché ciò sia indicato anche nel codice

Voglio solo aggiungere alle risposte di @SagiveSEO e @PieterGoosen.

C'è anche un potenziale killer delle prestazioni per quanto riguarda i tipi di post gerarchici :

Vale a dire la casella a discesa della pagina principale che utilizza wp_dropdown_pages().

Al momento è molto inefficace in quanto carica (quasi) tutte le pagine nella casella a discesa selezionata.

Quindi, se abbiamo un sito con molte pagine, questo può compromettere le prestazioni.

Immagina un sito con 1 milione di pagine ;-)

Questo è stato segnalato 6 anni fa con il biglietto n . 9864 . È ancora aperto, quindi puoi ancora contribuire alla soluzione di completamento automatico proposta.

Aggiornare:

Volevo solo menzionare alcuni filtri utili:

• wp_dropdown_pages- un filtro di uscita per la wp_dropdown_pages()funzione. Potrebbe essere utilizzato per aggiungere o fare eco ad HTML aggiuntivo, se necessario.
• get_pages- perché wp_dropdown_pages()chiama la get_pages()funzione.
• page_attributes_dropdown_pages_args- un filtro per gli argomenti wp_dropdown_pages()sugli post.php/post-new.phpschermi per i tipi di posta gerarchici.
• quick_edit_dropdown_pages_args- un filtro per l'argomento wp_dropdown_pages()sugli edit.phpschermi per i tipi di posta gerarchici.

che potrebbe essere utilizzato per risolvere il problema.

È possibile modificare l'output di wp_dropdown_pages()sullo post.phpschermo con:

add_filter( 'page_attributes_dropdown_pages_args', function( $dropdown_args, $post )
{
    if( 'page' === $post->post_type )
    {
        $dropdown_args['number']       = 10; // Limit the number of pages
        $dropdown_args['hierarchical'] = 0;  // Keep it non-hierarchical 
        $dropdown_args['offset']       = 1;  // Ideal for pagination
    }
    return $dropdown_args;
}, 10, 2 );

e similmente per lo edit.phpschermo per le pagine :

add_filter( 'quick_edit_dropdown_pages_args', function( $dropdown_args )
{
    $screen = get_current_screen();
    if( 'edit-page' === $screen->id )
    {
        $dropdown_args['number']       = 10; // Limit the number of pages
        $dropdown_args['hierarchical'] = 0;  // Keep it non-hierarchical
        $dropdown_args['offset']        = 1;  // Suitable for pagination
    }
    return $dropdown_args;
} );

Si noti che il secondo argomento di input ( $post) non è disponibile per questo callback del filtro.

Ovviamente è possibile semplicemente rimuovere il supporto degli attributi di pagina:

add_action( 'init', function()
{
    remove_post_type_support( $post_type = 'page', 'page-attributes' );

} );

ma allora potremmo anche usare un tipo di post non gerarchico ;-)

Elencare i genitori con l'impaginazione Ajax?

Dovrebbe essere possibile, con l'aiuto dei filtri di cui sopra, creare un elenco impaginato (non gerarchico) di genitori, che verrà aggiornato tramite Ajax. Forse le opzioni della casella di selezione potrebbero essere aggiornate, per mantenere il layout attuale. Questo sarebbe probabilmente? essere un approccio diverso rispetto alla casella di ricerca padre suggerita (su core trac), con completamento automatico.

Ok ... per chiunque visiti questo post - ho trovato la soluzione ... In
realtà ho riscontrato di nuovo questo problema (quando un sito ha molte pagine)

Il problema è questa riga quando si registra un tipo di post personalizzato:

'hierarchical'          => true,

Tutto quello che devi fare è cambiarlo in falso!

'hierarchical'          => false,

Spiegazione:
Sembra che quando "gerarchico" è impostato su true, ogni post si comporta come una pagina. Sto citando qui quindi non capisco davvero perché sia ​​importante, ma cambiando questa riga rimuovi il problema.

Ecco un esempio completo dal codice wordpress

add_action( 'init', 'codex_book_init' );
function codex_book_init() {
$labels = array(
    'name'               => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
    'singular_name'      => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),
    'menu_name'          => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ),
    'name_admin_bar'     => _x( 'Book', 'add new on admin bar', 'your-plugin-textdomain' ),
    'add_new'            => _x( 'Add New', 'book', 'your-plugin-textdomain' ),
    'add_new_item'       => __( 'Add New Book', 'your-plugin-textdomain' ),
    'new_item'           => __( 'New Book', 'your-plugin-textdomain' ),
    'edit_item'          => __( 'Edit Book', 'your-plugin-textdomain' ),
    'view_item'          => __( 'View Book', 'your-plugin-textdomain' ),
    'all_items'          => __( 'All Books', 'your-plugin-textdomain' ),
    'search_items'       => __( 'Search Books', 'your-plugin-textdomain' ),
    'parent_item_colon'  => __( 'Parent Books:', 'your-plugin-textdomain' ),
    'not_found'          => __( 'No books found.', 'your-plugin-textdomain' ),
    'not_found_in_trash' => __( 'No books found in Trash.', 'your-plugin-textdomain' )
);

$args = array(
    'labels'             => $labels,
    'public'             => true,
    'publicly_queryable' => true,
    'show_ui'            => true,
    'show_in_menu'       => true,
    'query_var'          => true,
    'rewrite'            => array( 'slug' => 'book' ),
    'capability_type'    => 'post',
    'has_archive'        => true,
    'hierarchical'       => false,
    'menu_position'      => null,
    'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
);

register_post_type( 'book', $args );
}