Intereting Posts
Передать $ page_id в новый WP_Query Если сообщение имеет ЛЮБОЙ термин, прикрепленный к нему, получите только первый Получение имени тега действия в действии Как использовать столбцы администратора declutter Как вернуть несколько аргументов из функции обратного вызова AJAX Написание модульного теста для add_menu_page Нажмите переключатель, чтобы установить значение текстового поля Как проверить, находится ли пользователь в определенной роли? Как конвертировать контактную форму 7 в сообщение после отправки? Передача переменной с страницы архива в шаблон по умолчанию Как я могу использовать только одну категорию на моей домашней странице? Как запустить PHP-скрипт из среды WordPress, например `wp shell`? Программно вставленные сообщения, не отображаемые в таблице сообщений цвет фона заголовка изменен после базы данных drop & import в phpmyadmin Динамический запрос WordPress AJAX

Ошибка загрузки пользовательской страницы типа сообщения

У меня есть настраиваемый тип сообщений «Свойства». У меня около 11 000 записей, и каждое свойство имеет около 400 настраиваемых полей ACF. Когда я перехожу на страницу «Свойства панели», чтобы редактировать их. Я получаю пустой экран. Я подумал, что, возможно, это причина полей ACF, но почему поля должны загружаться на странице листинга?

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

Если я уменьшу количество сообщений в моем CPT до пары тысяч … это сработает. Итак, что на самом деле загружается при загрузке страницы с листингами на панели управления? Я предположил, что это была только почта, а не метаданные. Это верно? Если это paginating, почему это имеет значение, сколько сообщений есть? Я полагаю, потому что столько сообщений с таким количеством данных postmeta, что они нажимают ограничение памяти, но даже на выделенном сервере с 8 ГБ оперативной памяти?

У меня на самом деле не работает тонна плагинов, менее 10, и ни одна из них не является тяжелой работой, кроме ACF. Мысли? Это сводит меня с ума.

EDIT: я узнал, что на странице с листингом он наверняка пытается загрузить всю постмету по какой-либо причине, даже если она не отображает ее здесь. И это заставляет использовать слишком много памяти для этого множества свойств. В любом случае я могу это предотвратить?

WordPress загружает значения метаданных для всех сообщений в текущем запросе, чтобы избежать выполнения SQL-запроса каждый раз, когда используется метаданные сообщения. Практически во всех случаях это дает огромное преимущество в производительности.

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

Итак, отключить это предварительное кэширование. Он контролируется с помощью update_post_meta_cache запроса update_post_meta_cache , для которой по умолчанию задано значение true для всех почтовых запросов. Чтобы отключить его, вам нужно настроить таргетинг на запросы, которые вас интересуют, и установить для него значение false. Пример:

 function wpse_160203( WP_Query $wp_query ) { if ( 'property' == $wp_query->get( 'post_type' ) ) { $wp_query->set( 'update_post_meta_cache', false ); } } if ( is_admin() ) { add_action( 'pre_get_posts', 'wpse_160203' ); } 

Это предотвратит предварительное кэширование почтовой мета для типа сообщения property в области администрирования. Если вы хотите сделать то же самое для front-end, просто удалите is_admin() условно, но имейте в виду, что вы увидите резкое увеличение SQL-запросов и, вероятно, не так много сокращения использования памяти, если вы действительно начнете использовать эти 400 почтовых полей.