Prime user meta in WP_User_Query

[spacedmonkey]

Ensure that user meta cache is primed in the WP_User_Query class, as user meta is used heavily in WP_User class. Prime all user meta in one query will result in less queries overall.

Trac ticket: https://core.trac.wordpress.org/ticket/55594

[spacedmonkey]

#55621 was marked as a duplicate.

[spacedmonkey]

Related: #53177

I'm not entirely following the patch here. Can you expand on the what the actual changes are here and their purpose? At first glance, it looks to be collapsing all and all_with_meta to be equivalent. Is that correct?

@TimothyBJacobs In WordPress 4.9, the WP_User class was changed so needs user meta. See
​https://github.com/WordPress/wordpress-develop/blob/4e830858061dbe37cda462e9a861bc7401fc6f6b/src/wp-includes/class-wp-user.php#L890-L906

So in the user REST API controller and is all other places that load a list of users, user meta is not primed correctly.

So should we update the docs for WP_User_Query to indicate that these function identically?

Thanks for explaining this, I was a little confused too. I can see why this is needed for both now with the changes to WP_User.

The all_with_meta option was effectively soft deprecated in 4.9 once all started populating the meta data. It could be simpler to document & throw a notice for the soft deprecation and convert it to all.

The all_with_meta option was effectively soft deprecated in 4.9 once all started populating the meta data. It could be simpler to document & throw a notice for the soft deprecation and convert it to all.

I have added a comment, to deprecate. I don't think we should hard deprecate, this param is used in a number of places in core and I guess in lots plugins as well.

[peterwilsoncc]

The ​linked pull request looks good to me as of ​cd881991e.

Marking as commit ready.

[spacedmonkey]

In 53655:

Users: Prime user meta in WP_User_Query class.

When querying 'fields' equal to 'all' using the WP_User_Query class, this returns an array of WP_User objects. A WP_User object requires user meta to be primed, as the user's role is stored in user meta. Ensure that all users meta is primed in a single request by calling the cache_users function when querying 'fields' equal to 'all'. Soft deprecate fields equal to all_with_meta as it now acts the same as 'fields' equal to 'all'.

Props Spacedmonkey, peterwilsoncc, mehulkaklotar, timothyblynjacobs, furi3r.
Fixes #55594.

Commited ​https://github.com/WordPress/wordpress-develop/commit/2db7debe8a2f0b2ea264d1765c549bbf5b44a052

[desrosj]

There are a lot of caching related changes in 6.1 and a dev note should be written collecting them all. Marking this for inclusion.

[obenland]

Just a heads up that this change (specifically ​this one) breaks plugins that called get_users() before plugins_loaded ran.

​https://stackoverflow.com/questions/74289047/wordpress-function-cache-users-not-found-after-update-to-6-1
​https://stackoverflow.com/questions/74290907/uncaught-error-call-to-undefined-function-cache-users

This query also surfaces broken sites in the wild: ​https://www.google.com/search?q=Call+to+undefined+function+cache_users()

[desrosj]

Thanks @obenland! I've opened #56988 to investigate any needed changes for 6.1.1.

@spacedmonkey was this ever included in a dev note? This one is still tagged needs-dev-note.

[pbiron]

Replying to desrosj:

@spacedmonkey was this ever included in a dev note? This one is still tagged needs-dev-note.

It's mentioned at the very bottom of ​https://make.wordpress.org/core/2022/10/11/performance-field-guide-for-wordpress-6-1/, but no details are provided

[spacedmonkey]

@pbiron @desrosj I did original want to write about it. But I couldn't think of anything more than, we prime user meta in WP_User_Query now. I don't think it needs a dev note really. I think we are good here.

[pbiron]

Replying to spacedmonkey:

@pbiron @desrosj I did original want to write about it. But I couldn't think of anything more than, we prime user meta in WP_User_Query now. I don't think it needs a dev note really. I think we are good here.

Agreed...there's not much to say about it :-)

[spacedmonkey]

#36508 was marked as a duplicate.