[wp-trac] [WordPress Trac] #58001: Lazy load user capabilities in WP_User object
WordPress Trac
noreply at wordpress.org
Sat Jan 18 15:00:42 UTC 2025
#58001: Lazy load user capabilities in WP_User object
--------------------------------------------+------------------------------
Reporter: spacedmonkey | Owner: flixos90
Type: enhancement | Status: reviewing
Priority: normal | Milestone: 6.8
Component: Users | Version:
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests early | Focuses: multisite,
| performance
--------------------------------------------+------------------------------
Comment (by spacedmonkey):
@flixos90 @joemcgill The core performance problem I want to solve here is
this:
In WP_Query, the update_post_author_caches function is called in the_post
method. This is just to prime all user objects in memory, as this user
object is used in generate_postdata, that calls get_userdata. This sets a
global authordata that should be a WP_User object.
On a simple site with one user, that is not really a problem. The single
user is loaded with its user meta. But once you have a set of authors,
from all different users, like 10 posts with 10 authors, then 10 lots of
user meta is loaded. If you have plugins that add lots of user meta keys,
like Woo does, then, if you are loading 10 users, with say 25 pieces of
user meta, that is already, 250 rows of meta loading. The real problem is
if then this is done on a multisite. If you have 10 users, with 25 pieces
of meta ( per site ) and they are across 15 sites, that is 10 x 25 x 15,
that is 3750 rows. Even with object caching enabled, that is a lot of data
that is loaded.
As far as I can see, not many plugins or themes use this global
authordata. We could consider loading setting the authordata global, but
creating a WP_User object without loading user meta. If you wanted to use
the authordata global, it would still be a valid WP_User, but would not
need the user meta. I would love to be able to remove the global
altogether, but that would be a BC break.
The current solution I have put forward is clever and fixes the problem
above but the magic methods are a bit of a workaround and have some risk
attached.
Thoughts.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/58001#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list