я получаю странную ошибку - белый экран в списке сообщений
для определенного пользовательского типа сообщения (только для этого)
- попытался деактивировать все плагины
- попытался проверить на наличие ошибок (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
Список сообщений загружается правильно ...
custom-post-types
fatal-error
Сагив SEO
источник
источник
pre_get_posts
, фильтрам запросов и т. д.pre_get_posts
. Однако, если ваша отладка активна и вы получаете белый экран без ошибок, я думаю, что должно бытьexit
или илиdie
, попробуйте найти их.Ответы:
Это расширить ваш собственный ответ:
Вот что говорит кодекс о
hierarchical
параметреКогда пользовательский тип записи установлен как иерархический, его поведение будет таким же, как и в типе записи
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
экран с помощью:и аналогично для
edit.php
экрана для страниц :Обратите внимание, что второй входной аргумент (
$post
) недоступен для этого обратного вызова фильтра.Конечно, можно просто удалить поддержку атрибутов страницы:
но тогда мы могли бы просто использовать неиерархический тип записи ;-)
Список родителей с Аяксом?
С помощью вышеупомянутых фильтров должно быть возможно создать разбитый на страницы (неиерархический) список родителей, который будет обновляться через ajax. Возможно, параметры окна выбора могут быть обновлены, чтобы сохранить текущий макет. Это вероятно? быть подходом, отличным от предложенного (на основной трассировке) родительского окна поиска, с автозаполнением.
источник
edit.php
экране @PieterGoosenwp_dropdown_pages()
проблемы является использование текстового поля поиска с автоматическим завершением ajax вместо текущий выпадающий список, когда количество страниц «большое». @PieterGoosenХорошо ... для тех, кто посещает этот пост - я нашел решение ...
я действительно столкнулся с этой проблемой снова (когда на сайте много страниц)
Проблема заключается в этой строке при регистрации пользовательского типа сообщения:
Все, что вам нужно сделать, это изменить его на false!
Расширение:
Похоже, что когда значение «иерархический» установлено в значение «истина», каждое сообщение ведет себя как страница. Я цитирую здесь, поэтому я не понимаю, почему это важно, но изменение этой строки устранит проблему.
источник
Вот полный пример из WordPress Codex
источник