Intereting Posts
Добавить элемент в пользовательское меню TinyMCE Как организовать загруженные носители в WP? Обновление страницы через редактор темы вызвало разрыв wp admin Как перенести сайт WordPress на другой сервер? Как использовать gettext для конкретной роли пользователя RSS-канал для динамического набора условий пользовательской таксономии Где определяется содержимое dynamic_sidebar? Как добавить возможность редактирования авторского права на существующую публикацию по администратора Проблема создания простого плагина Google Maps Как добавить фильтр post_distinct в WP_Comment_Query? Изменение тега кнопки отправки комментария WordPress предотвращает множественные короткие коды Перенаправить с «частной» страницы и functions.php, какой тег добавить в add_action ()? Недопустимый тип смещения в get_post_type_object ()? Загрузка БД на сервер из локального не соответствует датам публикации

Каковы действительные сроки использования current_user_can () и связанных с ним функций?

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

Однако также принято называть связанные функции, такие как current_user_can() раньше этого. Это по определению требуется для плагинов, которые работают с более ранними этапами загрузки (например, мой плагин Themebar для панели инструментов).

Документация не претендует на эту практику или против нее (которую я мог найти).

Однако некоторые плагины, похоже, подключаются к пользовательским функциям и всегда ожидают состояния пост- init .

Например, bbPress выдает следующее уведомление:

 // If the current user is being setup before the "init" action has fired, // strange (and difficult to debug) role/capability issues will occur. if ( ! did_action( 'after_setup_theme' ) ) { _doing_it_wrong( __FUNCTION__, __( 'The current user is being initialized without using $wp->init().', 'bbpress' ), '2.3' ); } 

Для быстрой демонстрации бросьте это в определение current_user_can() :

 function current_user_can( $capability ) { if ( ! did_action('after_setup_theme') ) { echo wp_debug_backtrace_summary(); } 

Кто «прав» в этой ситуации? Существует ли каноническое определение допустимого / запрещенного использования пользовательских функций перед init ?

Solutions Collecting From Web of "Каковы действительные сроки использования current_user_can () и связанных с ним функций?"

Единственным обязательным условием для current_user_can() является существующий wp_get_current_user() . Последнее определено в pluggable.php , поэтому вы можете использовать его после plugins_loaded .

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

В некоторых случаях, например, при изменении языка , вы должны получить доступ к текущему объекту пользователя раньше, поэтому ожидание after_setup_theme даже не является вариантом.

Если вы проверяете возможности пользователя перед init значит есть вероятность, что вы отвечаете за настройку текущего пользовательского объекта.

Если вы получаете доступ к пользователю после init , то вы уверены, что что- то еще уже настроит пользователя, в основном самого ядра.

Вот почему доступ к пользователю после init считается безопасным .

На самом деле, ранний доступ может разорвать некоторый фильтр, запущенный на determine_current_user .

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

Однако есть случаи (например, @toscho said), где вы не можете ждать до init, в тех случаях у вас нет выбора.

Единственный способ решить любую несовместимость – в любом случае, если у вас есть желание.

Решение, которое может работать в большинстве случаев (включая bbPress / BuddyPress), заключается в использовании следующей функции вместо current_user_can :

 function compat_current_user_can( $capability ) { if ( did_action( 'init' ) ) { return current_user_can( $capability ); } $user_id = apply_filters( 'determine_current_user', false ); return user_can( $user_id, $capability ); } 

Это позволяет проверить возможности текущего пользователя раньше, не устанавливая глобального пользователя, поэтому теоретически безопасно запускаться до init .

Проблема в том, что, как сказано выше, любой код, который переопределяет подключаемые функции, а не огни, determine_current_user разрывает его.

Я склонен думать, что BuddyPress и bbPress должны проверять что-то еще до выдачи сообщения _doing_it_wrong

Я изменил обе процедуры, чтобы проверить фактическую настройку $ current_user.

 global $current_user; if ( is_null( $current_user ) ) { _doing_it_wrong( ... ); } 

Уведомления больше не отображались.

Тестирование для did_action( "after_setup_theme" ) становится did_action( "after_setup_theme" ) к поясу.