唯一的先决条件current_user_can() 是现有的wp_get_current_user(). 后者的定义见pluggable.php, 所以你可以在之后使用它plugins_loaded.

这个_doing_it_wrong() 你在问题中引用的电话本身是错误的。我猜是你从BuddyPress或bbPress那里得到的。如果它们不等待那么长时间，它们都会陷入递归。还有其他更好的方法来防止递归。

在某些情况下，比如changing the locale, 您可以更早地访问当前用户对象，因此等待after_setup_theme 甚至都不是一个选择。

如果您以前检查过用户能力init 表示您有可能负责设置当前用户对象。

如果在init, 然后，您可以确定，其他一些东西已经设置了用户，大多数时间都是核心本身。

这就是为什么在之后访问用户init 被认为是安全的。

事实上，早期访问可能会破坏上运行的某些筛选器determine_current_user.

值得一提的是，它是一个“脆弱”的钩子，因为它有可能永远不会运行，只在可插入函数中触发。

但是，也有一些情况（如@toscho 如果你不能等到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 );
}

问题是，如上所述，任何重写可插入函数而不触发的代码determine_current_user 打破它。

我倾向于认为BuddyPress和bbPress应该在发布_doing_it_wrong 消息

我更改了这两个例程，以检查$current\\u user的实际设置。

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

测试did_action( "after_setup_theme" ) 成为皮带的支撑。