Tipo de publicación personalizada - lista de publicaciones - pantalla blanca de la muerte

Recibo un error extraño: pantalla blanca en la lista de publicaciones
para un tipo de publicación personalizado específico (solo para esa)

• Intenté desactivar todos los complementos
• intentado comprobar el error (depuración = verdadero)

Todavía nada,
la página simplemente no hace eco de nada ... (nada en la fuente también)

Estoy hablando de tal url en el administrador:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Aquí está la parte register_post_type que estoy 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');

¿Alguien se encontró con tal problema?
¿Se te ocurre alguna razón por la que esto pueda suceder?

Otra cosa extraña
cuando cambio esto:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

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

La lista de publicaciones se carga correctamente ...

Esto es para extender su propia respuesta:

Parece que cuando "jerárquico" se establece en verdadero, cada publicación se comporta como una página. Estoy citando aquí, así que realmente no entiendo por qué es importante, pero cambiar esta línea elimina el problema.

Esto es lo que dice el códice sobre el hierarchicalparámetro

jerárquico

(booleano) (opcional) Si el tipo de publicación es jerárquico (por ejemplo, página). Permite que se especifique Parent. El parámetro 'admite' debe contener 'atributos de página' para mostrar el cuadro de selección principal en la página del editor.

Predeterminado: falso

Nota:  este parámetro fue planeado para las páginas. Tenga cuidado al elegirlo para su tipo de publicación personalizada: si planea tener muchas entradas (por ejemplo, más de 100), se encontrará con un problema de memoria. Con este parámetro establecido en verdadero, WordPress buscará todas las entradas de ese tipo de publicación en particular, junto con todos los metadatos, en cada carga de la página de administración para su tipo de publicación.

Cuando un tipo de publicación personalizado se establece como jerárquico, su comportamiento será el mismo que el del tipo de publicación de compilación page. Al igual que las páginas, Wordpress intenta construir un árbol para mostrar el árbol jerárquico correcto con relaciones padre-hijo en el back-end. Como habrás notado, las páginas no están ordenadas por fecha en el back-end, sino por esta relación padre-hijo. Este comportamiento se puede ver fácilmente al visitar la Pagepágina en el back-end.

Esta operación es muy costosa ya que Wordpress necesita obtener cada página (o publicación de un tipo de publicación jerárquica) en cada carga de página y luego buscar las páginas principales y secundarias de esa / página específica para construir el árbol correcto para esa página / publicación específica . Si tiene una gran cantidad de páginas o publicaciones en su tipo de publicación personalizada jerárquica, la consulta simplemente se vuelve grande y excede los límites de memoria o el tiempo de espera, lo que conduce a un error fatal, por lo tanto, el WSOD.

Los tipos de publicaciones no jerárquicas como el tipo de publicación integrada postno tienen una jerarquía tal que las publicaciones de tipo de publicación no jerárquica no pueden tener publicaciones secundarias. Debido a que no hay necesidad de construir un árbol de relaciones padre-hijo (por razones obvias), Wordpress simplemente consulta 20 publicaciones ( IIRC ) por página ordenadas por fecha en el back-end y las muestra en contraste con las publicaciones jerárquicas de tipo de publicación donde Wordpress tiene que consulta todas las publicaciones a la vez, crea un árbol y luego muestra solo una cantidad x en las publicaciones agrupadas de acuerdo con su relación padre-hijo. Puede verificar este comportamiento en la Postpágina en el back-end

Por lo tanto, establecer un tipo de publicación personalizado en jerárquico le dice a Wordpress que debe construir una lista / árbol de publicaciones agrupadas por su relación padre-hijo y devolver esas publicaciones en esa configuración. Al establecer un tipo de publicación personalizado en no jerárquico, le está diciendo a Wordpress que omita toda la relación y solo devuelva una cantidad x de publicaciones por página ordenada por fecha de publicación

Espero que esto tenga un poco más de sentido para usted por qué debería evitar hacer que los tipos de publicaciones personalizadas sean jerárquicos, y por qué eso también se indica en el códice

Solo quiero agregar a las respuestas de @SagiveSEO y @PieterGoosen.

También hay un potencial asesino de rendimiento con respecto a los tipos de publicaciones jerárquicas :

A saber, el cuadro desplegable de la página principal que utiliza wp_dropdown_pages().

Actualmente es muy poco eficiente, ya que carga (casi) todas las páginas en el cuadro desplegable de selección.

Entonces, si tenemos un sitio con muchas páginas, esto puede afectar el rendimiento.

Solo imagine un sitio con 1 millón de páginas ;-)

Esto se informó hace 6 años con el boleto # 9864 . Todavía está abierto, por lo que aún puede contribuir a la solución propuesta de autocompletar.

Actualizar:

Solo quería mencionar algunos filtros útiles:

• wp_dropdown_pages- un filtro de salida para la wp_dropdown_pages()función. Puede usarse para agregar o hacer eco de HTML adicional si es necesario.
• get_pages- Porque wp_dropdown_pages()llama a la get_pages()función.
• page_attributes_dropdown_pages_args- un filtro para los argumentos wp_dropdown_pages()en las post.php/post-new.phppantallas para tipos de publicaciones jerárquicas.
• quick_edit_dropdown_pages_args- un filtro para el argumento wp_dropdown_pages()en las edit.phppantallas para tipos de publicaciones jerárquicas.

eso podría usarse para abordar el problema.

Es posible modificar la salida de wp_dropdown_pages()en la post.phppantalla 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 );

y de manera similar para la edit.phppantalla 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;
} );

Tenga en cuenta que el segundo argumento de entrada ( $post) no está disponible para esta devolución de llamada de filtro.

Por supuesto, es posible eliminar el soporte de atributos de la página:

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

} );

pero también podríamos usar un tipo de publicación no jerárquica en su lugar ;-)

¿Lista de padres con paginación ajax?

Debería ser posible, con la ayuda de los filtros anteriores, crear una lista paginada (no jerárquica) de padres, que se actualizaría a través de ajax. Tal vez las opciones del cuadro de selección podrían actualizarse, para mantener el diseño actual. Esto probablemente? debe ser un enfoque diferente al cuadro de búsqueda principal sugerido (en Core Trac), con finalización automática.

Ok ... para cualquiera que visite esta publicación, he encontrado la solución ... En
realidad, encontré estos problemas nuevamente (cuando un sitio tiene muchas páginas)

El problema es esta línea al registrar un tipo de publicación personalizada:

'hierarchical'          => true,

¡Todo lo que necesitas hacer es cambiarlo a falso!

'hierarchical'          => false,

Explenation:
Parece que cuando "jerárquico" se establece en verdadero, cada publicación se comporta como una página. Estoy citando aquí, así que realmente no entiendo por qué es importante, pero cambiar esta línea elimina el problema.

Aquí hay un ejemplo completo de WordPress Codex

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