Opened 3 months ago
Last modified 3 months ago
#61161 new defect (bug)
current_user_can fatal error
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | major | Version: | 6.6 |
Component: | Role/Capability | Keywords: | |
Focuses: | Cc: |
Description
current_user_can
uses https://developer.wordpress.org/reference/functions/wp_get_current_user/ internally, however this function is only loaded only much after current_user_can
is declared. This means using current_user_can
on e.g. mu_plugins_loaded
or plugin_loaded
hook will result in a fatal error.
Changing the wp_get_current_user()
call in there to _wp_get_current_user()
fixes that issue, but then it fails on wp_set_current_user()
which is pluggable too.
Change History (2)
#2
@
3 months ago
I know, but the problem is that this can accidentally make a plugin break another plugin or WP core alltogether with a fatal error.
e.g. plugin A:
<?php function my_cb_a( $value ) { if ( isset( $_GET['foo'] ) && current_user_can( 'administrator' ) ) { return 'UTF-8'; } return $value; } add_filter( 'pre_option_blog_charset', 'my_cb_a' );
plugin B:
<?php function my_cb_b() { $example = get_option( 'blog_charset' ); } add_action( 'plugins_loaded', 'my_cb_b' );
Note: See
TracTickets for help on using
tickets.
Note that it has always been documented that the earliest you can access the current user is in the
init
action.https://developer.wordpress.org/apis/hooks/action-reference/#actions-run-during-a-typical-request
So I would not expect it to work before
init
. (But it might make more sense to display a useful error message instead of crashing due to a missing function.)