Type de message personnalisé - liste des messages - écran blanc de la mort

je reçois une erreur étrange - écran blanc dans la liste des messages
pour un type de message personnalisé spécifique (juste pour celui-ci)

• essayé de désactiver tous les plugins
• tentative de vérification d'erreur (débogage = vrai)

Toujours rien
la page ne fait écho à rien ... (rien dans la source aussi)

Je parle d'une telle URL dans l'admin:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Voici la partie register_post_type que j'utilise:

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

Quelqu'un at-il rencontré une telle utilisation?
pouvez-vous penser à une raison pour laquelle cela pourrait arriver?

Une autre chose étrange
quand je change cela:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

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

La liste des articles se charge correctement ...

Ceci pour étendre votre propre réponse:

Il semble que lorsque "hiérarchique" est défini sur true, chaque publication se comporte comme une page. Je cite ici, donc je ne comprends pas vraiment pourquoi c'est important, mais changer cette ligne résout le problème.

Voici ce que dit le codex sur le hierarchicalparamètre

hiérarchique

(booléen) (facultatif) Indique si le type de publication est hiérarchique (par exemple, page). Permet au parent d'être spécifié. Le paramètre «supports» doit contenir des «attributs de page» pour afficher la boîte de sélection parent sur la page de l'éditeur.

Par défaut: faux

Remarque:  ce paramètre était prévu pour Pages. Soyez prudent, lorsque vous le choisissez pour votre type de publication personnalisé - si vous prévoyez d'avoir de nombreuses entrées (disons - plus de 100), vous rencontrerez un problème de mémoire. Avec ce paramètre défini sur true, WordPress récupérera toutes les entrées de ce type de publication particulier, ainsi que toutes les métadonnées, sur chaque page d'administration chargée pour votre type de publication.

Lorsqu'un type de publication personnalisé est défini comme hiérarchique, son comportement sera le même que le type de publication intégré page. Comme les pages, Wordpress essaie de créer une arborescence pour afficher l'arborescence hiérarchique correcte avec les relations parent-enfant à l'arrière-plan. Comme vous l'avez peut-être remarqué, les pages ne sont pas triées par date dans le back-end, mais par cette relation parent-enfant. Vous pouvez facilement voir ce comportement lorsque vous visitez la Pagepage en arrière-plan.

Cette opération est très coûteuse car Wordpress doit obtenir chaque page (ou publication à partir d'un type de publication hiérarchique) à chaque chargement de page , puis rechercher les pages parent et enfant de cette page / publication spécifique pour créer une arborescence correcte pour cette page / publication spécifique . Si vous avez une grande quantité de pages ou de publications dans votre type de publication personnalisé hiérarchique, la requête devient simplement trop grande et dépasse les limites de mémoire ou expire, ce qui conduit à une erreur fatale, d'où le WSOD.

Les types de publication non hiérarchiques tels que le type de publication intégré postn'ont pas une telle hiérarchie que les publications de type de publication non hiérarchiques ne peuvent pas avoir de publications enfant. Parce qu'il n'est pas nécessaire de créer une arborescence de relations parent-enfant (pour des raisons évidentes), Wordpress interroge simplement 20 publications ( IIRC ) par page classées par date dans le back-end et les affiche contrairement aux publications de type de publication hiérarchique où Wordpress doit interroger tous les messages à la fois, créer une arborescence, puis afficher uniquement un montant x sur les messages groupés en fonction de leur relation parent-enfant. Vous pouvez vérifier ce comportement dans la Postpage en arrière-plan

Donc, définir un type de publication personnalisé sur hiérarchique indique à Wordpress qu'il doit créer une liste / arborescence de publications groupées par leur relation parent-enfant et renvoyer ces publications dans cette configuration. En définissant un type de publication personnalisé sur non hiérarchique, vous dites à Wordpress d'ignorer toute la relation et de renvoyer simplement un nombre x de publications par page ordonnées par date de publication

J'espère que cela vous donnera un peu plus de sens pourquoi vous devriez éviter de rendre les types de messages personnalisés hiérarchiques, et pourquoi cela est également indiqué dans le codex

Je veux juste ajouter aux réponses de @SagiveSEO et @PieterGoosen.

Il existe également un tueur de performances potentiel concernant les types de publication hiérarchiques :

À savoir la liste déroulante de la page parent qui utilise wp_dropdown_pages().

C'est actuellement très inefficace car il charge (presque) toutes les pages dans la liste déroulante de sélection.

Donc, si nous avons un site avec plusieurs pages, cela peut nuire aux performances.

Imaginez un site avec 1 million de pages ;-)

Cela a été signalé il y a 6 ans avec le ticket # 9864 . Il est toujours ouvert afin que vous puissiez toujours contribuer à la solution d'auto-complétion proposée.

Mise à jour:

Je voulais juste mentionner quelques filtres utiles:

• wp_dropdown_pages- un filtre de sortie pour la wp_dropdown_pages()fonction. Peut être utilisé pour ajouter ou faire écho du HTML supplémentaire si nécessaire.
• get_pages- car wp_dropdown_pages()appelle la get_pages()fonction.
• page_attributes_dropdown_pages_args- un filtre pour les arguments wp_dropdown_pages()sur les post.php/post-new.phpécrans pour les types de messages hiérarchiques.
• quick_edit_dropdown_pages_args- un filtre pour l'argument wp_dropdown_pages()sur les edit.phpécrans pour les types de messages hiérarchiques.

qui pourrait être utilisé pour résoudre le problème.

Il est possible de modifier la sortie de wp_dropdown_pages()sur l' post.phpécran avec:

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

et de même pour l' edit.phpécran des pages :

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

Notez que le deuxième argument d'entrée ( $post) n'est pas disponible pour ce rappel de filtre.

Il est bien sûr possible de supprimer simplement le support des attributs de page:

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

} );

mais alors nous pourrions aussi bien utiliser un type de publication non hiérarchique à la place ;-)

Liste des parents avec pagination ajax?

Il devrait être possible, à l'aide des filtres ci-dessus, de créer une liste paginée (non hiérarchique) de parents, qui serait mise à jour via ajax. Peut-être que les options de la boîte de sélection pourraient être mises à jour pour conserver la disposition actuelle. Ce serait probablement? être une approche différente de la boîte de recherche parent suggérée (sur le traceur principal), avec complétion automatique.

Ok ... pour tous ceux qui visitent ce message - j'ai trouvé la solution ...
j'ai en fait rencontré à nouveau ces problèmes (lorsqu'un site a beaucoup de pages)

Le problème est cette ligne lors de l'enregistrement d'un type de publication personnalisé:

'hierarchical'          => true,

Tout ce que vous devez faire est de le changer en faux!

'hierarchical'          => false,

Explication:
Il semble que lorsque "hiérarchique" est défini sur true, chaque publication se comporte comme une page. Je cite ici, donc je ne comprends pas vraiment pourquoi c'est important, mais changer cette ligne résout le problème.

Voici un exemple complet du 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 );
}