Пользовательский тип сообщения - список сообщений - белый экран смерти

я получаю странную ошибку - белый экран в списке сообщений
для определенного пользовательского типа сообщения (только для этого)

• попытался деактивировать все плагины
• попытался проверить на наличие ошибок (debugging = true)

Все еще ничего,
что страница просто не повторяет ничего ... (ничего в источнике тоже)

Я говорю о таком URL в админке:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Вот часть register_post_type, которую я использую:

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

Кто-нибудь сталкивался с такой проблемой?
Вы можете придумать причину, по которой это может произойти?

Еще одна странная вещь,
когда я изменяю это:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Для этого:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt&orderby=date&order=desc

Список сообщений загружается правильно ...

Это расширить ваш собственный ответ:

Похоже, что когда для «иерархического» задано значение «истина», каждое сообщение ведет себя как страница. Я цитирую здесь, поэтому я не понимаю, почему это важно, но изменение этой строки устранит проблему.

Вот что говорит кодекс о hierarchicalпараметре

иерархическая

(булево) (необязательно) Является ли тип сообщения иерархическим (например, страница). Позволяет указать родителя. Параметр 'Support' должен содержать 'атрибуты страницы', чтобы показать родительское поле выбора на странице редактора.

По умолчанию: false

Примечание:  этот параметр был запланирован для страниц. Будьте внимательны, выбирая его для своего пользовательского типа записи - если вы планируете иметь много записей (скажем, более 100), у вас возникнет проблема с памятью. Если для этого параметра задано значение true, WordPress будет извлекать все записи этого конкретного типа записи вместе со всеми метаданными на каждой странице администрирования для загрузки вашего типа записи.

Когда пользовательский тип записи установлен как иерархический, его поведение будет таким же, как и в типе записи page. Как и страницы, Wordpress пытается построить дерево для отображения правильного иерархического дерева с родительскими и дочерними отношениями на заднем плане. Как вы могли заметить, страницы сортируются не по дате в серверной части, а по этим отношениям родитель-потомок. Такое поведение вы можете легко увидеть при посещении Pageстраницы в бэк-энде.

Эта операция очень дорогая, так как Wordpress должен получать каждую страницу (или пост из иерархического типа поста) при каждой загрузке страницы, а затем искать родительские и дочерние страницы этой / постовой страницы, чтобы построить правильное дерево для этой конкретной страницы / поста. , Если у вас большое количество страниц или сообщений в иерархическом пользовательском типе сообщений, запрос просто становится большим и превышает ограничения памяти или тайм-ауты, что приводит к фатальной ошибке, отсюда и WSOD.

Неиерархические типы postзаписей, такие как сборка в типе записей, не имеют такой иерархии, поскольку неиерархические типы записей не могут иметь дочерние записи. Поскольку нет необходимости создавать дерево отношений «родитель-потомок» (по понятным причинам), Wordpress просто запрашивает 20 ( IIRC ) постов на страницу, упорядоченных по дате, во внутреннем интерфейсе и отображает их в отличие от иерархических постов типа поста, где Wordpress должен запросить все сообщения сразу, построить дерево, а затем отобразить только сумму x для сообщений, сгруппированных в соответствии с их родительско-дочерними отношениями. Вы можете проверить это поведение на Postстранице в конце

Так что установка пользовательского типа поста в иерархический режим говорит Wordpress, что он должен создать список / дерево постов, сгруппированных по их родительско-дочерним отношениям, и вернуть эти посты в этой конфигурации. Установив нестандартный тип пользовательского поста, вы говорите Wordpress пропустить весь процесс отношений и просто возвращать х постов на странице, упорядоченных по дате поста.

Я надеюсь, что для вас это будет иметь больше смысла, почему вы должны избегать создания пользовательских типов записей иерархически, и почему это также указано в кодексе

Я просто хочу добавить к ответам @SagiveSEO и @PieterGoosen.

Существует также потенциальный фактор снижения производительности в отношении иерархических типов записей:

А именно , используется выпадающий список родительской страницыwp_dropdown_pages() .

В настоящее время это очень неэффективно, поскольку загружает (почти) все страницы в выпадающий список выбора.

Так что если у нас есть сайт с большим количеством страниц, это может снизить производительность.

Представьте себе сайт с 1 миллионом страниц ;-)

Об этом 6 лет назад сообщили с билетом № 9864 . Он все еще открыт, так что вы можете внести свой вклад в предлагаемое решение для автозаполнения.

Обновить:

Я просто хотел упомянуть некоторые полезные фильтры:

• wp_dropdown_pages- выходной фильтр для wp_dropdown_pages()функции. Может быть использовано для добавления или отображения некоторого дополнительного HTML-кода, если это необходимо.
• get_pages- потому что wp_dropdown_pages()вызывает get_pages()функцию.
• page_attributes_dropdown_pages_args- фильтр для аргументов wp_dropdown_pages()на post.php/post-new.phpэкранах для иерархических типов записей.
• quick_edit_dropdown_pages_args- фильтр аргументов wp_dropdown_pages()на edit.phpэкранах для иерархических типов постов.

это может быть использовано для решения проблемы.

Можно изменить вывод wp_dropdown_pages()на post.phpэкран с помощью:

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

и аналогично для edit.phpэкрана для страниц :

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

Обратите внимание, что второй входной аргумент ( $post) недоступен для этого обратного вызова фильтра.

Конечно, можно просто удалить поддержку атрибутов страницы:

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

} );

но тогда мы могли бы просто использовать неиерархический тип записи ;-)

Список родителей с Аяксом?

С помощью вышеупомянутых фильтров должно быть возможно создать разбитый на страницы (неиерархический) список родителей, который будет обновляться через ajax. Возможно, параметры окна выбора могут быть обновлены, чтобы сохранить текущий макет. Это вероятно? быть подходом, отличным от предложенного (на основной трассировке) родительского окна поиска, с автозаполнением.

Хорошо ... для тех, кто посещает этот пост - я нашел решение ...
я действительно столкнулся с этой проблемой снова (когда на сайте много страниц)

Проблема заключается в этой строке при регистрации пользовательского типа сообщения:

'hierarchical'          => true,

Все, что вам нужно сделать, это изменить его на false!

'hierarchical'          => false,

Расширение:
Похоже, что когда значение «иерархический» установлено в значение «истина», каждое сообщение ведет себя как страница. Я цитирую здесь, поэтому я не понимаю, почему это важно, но изменение этой строки устранит проблему.

Вот полный пример из 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 );
}