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

9

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

  • попытался деактивировать все плагины
  • попытался проверить на наличие ошибок (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

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

Сагив SEO
источник
1
во включенном коде нет ничего, что могло бы вызвать это, убедиться, что у вас нет ничего, что мешало бы запросам pre_get_posts, фильтрам запросов и т. д.
Мило
спасибо, мило ... искал pre_get_posts в файлах и ничего не смог найти - это странно! ; <(спасибо за попытку помочь.
Sagive SEO
Согласитесь с @Milo, должно быть что-то, действующее на запрос. Обратите внимание, что есть тонны фильтров, которые действуют не только на запрос pre_get_posts. Однако, если ваша отладка активна и вы получаете белый экран без ошибок, я думаю, что должно быть exitили или die, попробуйте найти их.
gmazzap
это идея gr8! буду делать GM спасибо за ваш вклад
Sagive SEO
Есть ли успехи в этом? Имея ту же проблему.
Nic

Ответы:

8

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

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

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

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

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

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

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

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

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

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

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

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

Питер Гусен
источник
очень круто @pietergoosen большое спасибо за то, что поделились - я ненавижу просто обходиться без причины;)
Sagive SEO
С удовольствием. Наслаждайтесь :-)
Питер Гусен
6

Я просто хочу добавить к ответам @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. Возможно, параметры окна выбора могут быть обновлены, чтобы сохранить текущий макет. Это вероятно? быть подходом, отличным от предложенного (на основной трассировке) родительского окна поиска, с автозаполнением.

birgire
источник
Спасибо за эту информацию. Что-то посмотреть в ближайшем будущем ;-)
Питер Гусен
Я обнаружил это несколько недель назад, когда приступил к установке с несколькими тысячами страниц. Я был удивлен, увидев, что в раскрывающемся списке родительской страницы есть тысячи вариантов ;-) Это также часть быстрого редактирования на edit.phpэкране @PieterGoosen
birgire
1
да, и с текущим состоянием ядра я бы не рекомендовал использовать более ~ 100 страниц, если только у вас нет хорошего сервера => нам просто нужно найти способ использовать неиерархические посты вместо страниц для большого количества элементов ;-)
Birgire
2
может быть, если бэкэнд сохранит все объекты в памяти и синхронизирует их с базой данных только с помощью некоторого умного «diff» ;-) Я думаю, что одним из предложенных решений wp_dropdown_pages()проблемы является использование текстового поля поиска с автоматическим завершением ajax вместо текущий выпадающий список, когда количество страниц «большое». @PieterGoosen
birgire
1
@ialocin ценится что-нибудь информативное, даже философские взгляды ;-)
Питер Гусен
3

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

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

'hierarchical'          => true,

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

'hierarchical'          => false,

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

Сагив SEO
источник
-1

Вот полный пример из 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 );
}
emilushi
источник
как дела с копией и вставкой? почему вы вставили этот код сюда?
Sagive SEO
Извините, не вижу ваш код, я проверял его из приложения adroid, но не знаю, почему он когда-то скрывает контент, а иногда очень напрягает
emilushi