[wp-trac] [WordPress Trac] #59000: Add a check for wp_get_current_user to current_user_can
WordPress Trac
noreply at wordpress.org
Mon Aug 28 22:10:12 UTC 2023
#59000: Add a check for wp_get_current_user to current_user_can
-------------------------------------+------------------------------
Reporter: scruffian | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Users | Version:
Severity: normal | Resolution:
Keywords: 2nd-opinion needs-patch | Focuses:
-------------------------------------+------------------------------
Comment (by azaozz):
Replying to [comment:14 okat]:
> Also, for plugin authors, not being able to use
`$wp_theme->get_stylesheet()` before the `plugins_loaded` action could be
perceived as a breaking change. Not a few plugins (such as CoBlocks,
Elementor, WooCommerce) will be affected. That's the reason I changed the
order of loading in https://github.com/WordPress/wordpress-
develop/pull/5028 while keeping the current behavior.
Thinking we may be misunderstanding one another a bit :)
Calling `$wp_theme->get_stylesheet()` is unaffected by the proposed
PR/patch. Any plugin or theme or core code that does this before `wp-
includes/pluggable.php` is loaded is "doing it wrong".
The PR only affects the case that seems to happen because of the code in
theme-previews.php where filters and actions are added in the global
scope, here: https://core.trac.wordpress.org/browser/tags/6.3/src/wp-
includes/theme-previews.php#L78.
Looking at this more, if the theme-previews.php file is loaded later (as
in the PR) it may also cause problems if a plugin is trying to remove one
of these filters from "loose code" that's defined in global scope, as
these won't exist when the plugin is loaded. That seems very unlikely but
not impossible.
> Could we confirm if taking this direction is acceptable? Do you have any
thoughts?
Thinking the underlying problem here is with calling
`$wp_theme->get_stylesheet()` before `pluggable.php` is loaded. That needs
to be fixed. As far as I see the only way to fix it would be to educate
plugin authors not to do it. In any case, having a "loose" functional code
that runs in global scope in a plugin's file is a big "bad practice"
usually. Triggering "doing it wrong" in such cases seems warranted.
There seem to be couple alternatives to fix the particular case with
theme-previews.php. Perhaps instead of moving the file it would be better
to move the code that is adding the actions and filters to a function, and
then load that function on `plugins_loaded` (add the hook for it in
default_filters.php)? Then the file would not need moving and there will
be no "loose code" in the global scope there.
Moving this tentatively to 6.3.2 for a review providing there is a good
patch for it.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/59000#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list