Tipo de postagem personalizada - lista de postagens - tela branca da morte

Estou recebendo um erro estranho - tela branca na lista de postagens
de um tipo de postagem personalizada específico (apenas para aquela)

• tentei desativar todos os plugins
• tentou verificar se há erro (depuração = true)

Ainda assim,
a página simplesmente não reproduz nada ... (também nada na fonte)

Estou falando desse URL no admin:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Aqui está a parte register_post_type que estou 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');

Alguém encontrou um issuse?
você pode pensar em uma razão pela qual isso pode acontecer?

Outra coisa estranha
quando eu mudo isso:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

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

A lista de postagens carrega corretamente ...

Isso é para estender sua própria resposta:

Parece que quando "hierárquico" é definido como verdadeiro, cada postagem se comporta como uma página. Estou citando aqui, então realmente não entendo por que isso importa, mas alterar essa linha remove o problema.

Aqui está o que o códice diz sobre o hierarchicalparâmetro

hierárquico

(booleano) (opcional) Se o tipo de postagem é hierárquico (por exemplo, página). Permite que o pai seja especificado. O parâmetro 'suporta' deve conter 'atributos de página' para mostrar a caixa de seleção pai na página do editor.

Padrão: false

Nota:  este parâmetro foi planejado para Páginas. Cuidado, ao escolher o seu tipo de postagem personalizado - se você planeja ter muitas entradas (por exemplo, mais de 100), ocorrerá um problema de memória. Com esse parâmetro definido como true, o WordPress buscará todas as entradas desse tipo de postagem específico, juntamente com todos os metadados, em cada carregamento da página de administração do seu tipo de postagem.

Quando um tipo de postagem personalizado é definido como hierárquico, seu comportamento será o mesmo da construção no tipo de postagem page. Como as páginas, o Wordpress tenta criar uma árvore para exibir a árvore hierárquica correta com os relacionamentos pai-filho no back-end. Como você deve ter notado, as páginas não são classificadas por data no back-end, mas por esse relacionamento pai-filho. Esse comportamento você pode ver facilmente ao visitar a Pagepágina no back-end.

Essa operação é muito cara, pois o Wordpress precisa obter cada página (ou postagem de um tipo hierárquico de postagem) em cada carregamento de página e, em seguida, procurar as páginas pai e filha dessa página / publicação específica para criar a árvore correta para essa página / publicação específica. . Se você tiver uma grande quantidade de páginas ou postagens no seu tipo de postagem personalizada hierárquica, a consulta simplesmente se tornará grande e excederá os limites de memória ou o tempo limite, o que leva a um erro fatal, daí o WSOD.

Os tipos de postagem não hierárquicos, como a construção no tipo de postagem post, não têm uma hierarquia, pois as postagens não hierárquicas não podem ter postagens filho. Como não há necessidade de criar uma árvore de relacionamento pai-filho (por razões óbvias), o Wordpress simplesmente consulta 20 postagens ( IIRC ) por página ordenadas por data no back-end e as exibe em contraste com as postagens hierárquicas do tipo post onde o Wordpress precisa consulte todas as postagens de uma só vez, construa uma árvore e exiba apenas um valor de x nas postagens agrupadas de acordo com o relacionamento pai-filho. Você pode verificar esse comportamento na Postpágina no back-end

Portanto, definir um tipo de postagem personalizado como hierárquico informa ao Wordpress que ele deve criar uma lista / árvore de postagens agrupadas por seu relacionamento pai-filho e retornar essas postagens nessa configuração. Definindo um tipo de postagem personalizado como não hierárquico, você está dizendo ao Wordpress para pular toda a questão do relacionamento e retornar apenas uma quantidade x de mensagens por página ordenada pela data da postagem

Espero que isso faça um pouco mais de sentido para você, por que você deve evitar hierarquizar tipos de postagem personalizados e por que isso também é afirmado no codex

Eu só quero adicionar às respostas de @SagiveSEO e @PieterGoosen.

Há também um potencial matador de desempenho em relação aos tipos de postagem hierárquica :

Ou seja, a caixa suspensa da página pai que usa wp_dropdown_pages().

No momento, é muito ineficiente, pois carrega (quase) todas as páginas na caixa suspensa de seleção.

Portanto, se tivermos um site com muitas páginas, isso poderá prejudicar o desempenho.

Imagine um site com 1 milhão de páginas ;-)

Isso foi relatado há 6 anos com o ticket # 9864 . Ainda está aberto para que você ainda possa contribuir com a solução de preenchimento automático proposta.

Atualizar:

Eu só queria mencionar alguns filtros úteis:

• wp_dropdown_pages- um filtro de saída para a wp_dropdown_pages()função. Pode ser usado para acrescentar ou repetir algum HTML extra, se necessário.
• get_pages- porque wp_dropdown_pages()chama a get_pages()função
• page_attributes_dropdown_pages_args- um filtro para os argumentos wp_dropdown_pages()nas post.php/post-new.phptelas para tipos de postagem hierárquicos.
• quick_edit_dropdown_pages_args- um filtro para o argumento wp_dropdown_pages()nas edit.phptelas para tipos de postagem hierárquicos.

que poderia ser usado para resolver o problema.

É possível modificar a saída wp_dropdown_pages()na post.phptela com:

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 da mesma forma para a edit.phptela de páginas :

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

Observe que o segundo argumento de entrada ( $post) não está disponível para esse retorno de chamada do filtro.

É claro que é possível remover apenas o suporte aos atributos da página:

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

} );

mas podemos usar apenas um tipo de postagem não hierárquica ;-)

Listar pais com paginação ajax?

Deveria ser possível, com a ajuda dos filtros acima, criar uma lista paginada (não hierárquica) de pais, que seria atualizada via ajax. Talvez as opções da caixa de seleção possam ser atualizadas, para manter o layout atual. Provavelmente isso? seja uma abordagem diferente da caixa de pesquisa pai sugerida (no core trac), com preenchimento automático.

Ok ... para quem visita este post - encontrei a solução ...
encontrei esses problemas novamente (quando um site tem muitas páginas)

O problema é esta linha ao registrar um tipo de postagem personalizado:

'hierarchical'          => true,

Tudo que você precisa fazer é alterá-lo para falso!

'hierarchical'          => false,

Explicação:
Parece que quando "hierárquico" é definido como verdadeiro, cada postagem se comporta como uma página. Estou citando aqui, então realmente não entendo por que isso importa, mas alterar essa linha remove o problema.

Aqui está um exemplo completo do codex 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 );
}