У меня есть этот фрагмент кода в моем плагине Meteor Slides, который загружает таблицу стилей на страницы администратора только для пользовательского типа сообщений слайдов:
add_action('admin_head', 'meteorslides_admin_css');
function meteorslides_admin_css() {
global $post_type;
if (($_GET['post_type'] == 'slide') || ($post_type == 'slide')) :
echo "<link type='text/css' rel='stylesheet' href='" . plugins_url('/css/meteor-slides-admin.css', __FILE__) . "' />";
endif;
}
Этот код работает нормально и не вызывает никаких проблем, но в режиме отладки он вызывает эту ошибку, которую я хотел бы устранить:
// Notice: Undefined index: post_type in C:\Program Files\xampp\htdocs\slides\wp-content\plugins\meteor-slides-1.3\meteor-slides-plugin.php on line 476
Я не смог исправить эту ошибку, есть ли у кого-нибудь предложения или другой способ добавить таблицу стилей на страницы администратора определенного типа сообщений?
Вам необходимо проверить наличие
'post_type'
в качестве индекса$_GET
перед его использованием:Кроме того, вы должны использовать эту
wp_enqueue_style
функцию вместо того, чтобы повторять свою таблицу стилей по адресу'admin_head'
:Подробнее о wp_enqueue_style здесь.
Большое спасибо, Джон, имеет смысл, что мне нужно проверить это, прежде чем использовать его, и это полностью устранило ошибку, которую я получал.
И спасибо за внимание к wp_enqueue_style, я использую wp_enqueue_script во всех своих JavaScript, но я не знал, что это существует для таблиц стилей. Это не сработало для меня с первого раза, но мне придется прочитать об этом и понять это.
Кажется, я знаю, почему это не сработало. Я думал, ты зацепился за
admin_init
;admin_head
слишком поздно ставить стиль в очередь. Я бы предложил зацепиться'admin_enqueue_scripts'
. Он запускается перед печатью стилей и скриптов и не должен изменять функциональность вашего кода.Еще раз спасибо, Джон, запуск wp_enqueue_style на admin_enqueue_scripts сработал отлично. Теперь у меня есть все таблицы стилей в моем плагине, правильно поставленные в очередь!
Спасибо за информацию t31os, буду пробовать! Раньше я пытался использовать admin_print_styles, но у меня возникли проблемы с его работой с пользовательскими типами сообщений.
Есть хуки для добавления действий к определенным страницам… и дополнительно различные переменные, которые содержат данные о текущей странице, типе записи, родительском файле и т.д..
admin_print_styles
будет правильным хуком для использования стилей в очереди, а для страницы редактирования ваше действие может выглядеть примерно так.В этом случае хук
edit.php
, каждая страница администратора имеет аналогичный хук. WordPressadmin_header.php
в основном имеет набор действий, которые срабатывают, которые выглядят так…И
admin.php
устанавливает суффикс ловушки со следующим..Помимо всего основного кода, пример функции, которую я разместил выше, является рабочим примером, который вы можете использовать для таргетинга на экран редактирования сообщений (пользовательский тип или нет)….
Надеюсь, это поможет..