[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