[wp-trac] [WordPress Trac] #43869: Do not initialize current user too early in `get_user_locale()`

[WordPress Trac]

#43869: Do not initialize current user too early in `get_user_locale()`
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Bootstrap/Load                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion                                        |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 @ocean90

 I generally think initializing the current user early violates
 expectations resulting from the typical flow of the bootstrap process and
 the order of things happening in `wp-settings.php`.

 The current user is generally initialized right before the `init` hook and
 the process of initializing fires a `set_current_user` hook. You should be
 able to expect that, when using this hook, you're just before `init` (or
 later) in the flow. Since a call to `load_plugin_textdomain()` (usually
 called early on `plugins_loaded`) will currently set the current user, but
 many plugins initialize their entire functionality on `plugins_loaded`
 too, making it hard and sometimes impossible to use the `set_current_user`
 hook under correct assumptions.

 The problem I personally ran into was the following: I was filtering
 `user_has_cap` in a plugin and relying on plugin functionality that is
 loaded on `plugins_loaded`. However, since the current user was
 initialized before, the `kses_init()` function was executed (which is
 hooked into `set_current_user` by core). That function checks whether
 `current_user_can( 'unfiltered_html' )`, causing the `user_has_cap` filter
 to trigger unexpectedly early, where some of the plugin functionality was
 not yet available.

 Back to an approach for fixing this: If the general consensus is that
 setting the current user that early is ''not'' unexpected or if my initial
 patch is considered a little too risky/clunky, I'd like to at least have
 no unnecessary `user_has_cap` filter fire as early. We can ensure this by
 executing the line `add_action( 'set_current_user', 'kses_init' )` on
 `init`, to ensure it only fires afterwards. It shouldn't be necessary to
 initialize KSES behavior before that anyway. In case a process changes the
 current user, the behavior is still reinitialized correctly, since we
 still have the filter in place. But before `init`, it's pretty useless
 anyway.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43869#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform