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

WordPress Trac noreply at wordpress.org
Thu Apr 26 13:58:48 UTC 2018


#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          |   Keywords:  needs-patch needs-unit-tests
  Focuses:                  |
----------------------------+------------------------------------------
 The current user in WordPress is typically initialized right before the
 `init` action, in `wp-settings.php`. While WordPress has measures in place
 to initialize the current user on request, this is rather unexpected and
 we should try to avoid it.

 There is one function in core that causes the current user to be
 initialized in such an unexpected way, namely the `get_user_locale()`
 function. It is at least called by `load_default_textdomain()` (after the
 `setup_theme` hook), but most times even earlier, when plugins call
 `load_plugin_textdomain()` (usually on `plugins_loaded`).

 Of course it's necessary to load the user-specific locale that early, so
 it's not an option to set it up later. However, it shouldn't be necessary
 for `get_user_locale()` to set the current user.

 * First of all, it doesn't need to access a full user object. Initializing
 a user object is a heavy process (unless the current user), and all we
 need to do here is look up a meta value for the `locale`, for which a
 user's ID is sufficient.
 * I suggest to do the following: If no `$user_id` is passed, call
 `get_current_user_id()` if we're at a point in the bootstrap flow where
 the current user is already set up. Otherwise, we can use the filter
 `determine_current_user` which is internally used by
 `_wp_get_current_user()` and returns the current user's ID on success. We
 might wanna consider centralizing that logic in a utility function.

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


More information about the wp-trac mailing list