Invalid parameters in Custom CSS and Changeset queries

[dlh]

The update_term_meta_cache parameter is passed to WP_Query in wp_get_custom_css_post() and WP_Customize_Manager::find_changeset_post_id(). As far as I can tell, update_term_meta_cache is allowed in only WP_Term_Query and isn't handled by WP_Query.

The attached patch would swap in 'update_post_term_cache' => false and 'lazy_load_term_meta' => false based on the inference that neither query is supposed to cause side-effects with terms or term meta.

(Side note: Two tests in Tests_Query_MetaQuery also pass update_term_meta_cache to WP_Query. I've attached a second patch for those, if a fix is warranted.)

[dlh]

"Side note" patch

[celloexpressions]

Introduced in 4.7 and a small fix, moving to 4.7.1 for further investigation.

[dd32]

Is this change needed in 4.7.1? At the worst a few extra queries will be performed? Feels like a punt to 4.8

Pinging @boonebgorges for 39194.2.diff​, @westonruter for 39194.diff​

[westonruter]

@dd32 that's right. The impact is very small. It's purely for performance, to reduce the number of queries.

[boonebgorges]

Replying to westonruter:

@dd32 that's right. The impact is very small. It's purely for performance, to reduce the number of queries.

+1. @dd32 Your call if you think it's worth including in 4.7.1. Patches look good to me.

[jbpaul17]

Per today's bug scrub in #core: @dd32 will commit this to trunk today, but will be punted to 4.8.

[westonruter]

Instead of punting for 4.8 I think it should be part of 4.7.2:

What goes in a minor release will broaden a bit, which I know is something we have to approach carefully, but performance is very important and improvements will be something I will consider for being in a minor release.

Ref. ​https://make.wordpress.org/core/2017/01/04/focus-tech-and-design-leads/#comment-31894

[dd32]

@westonruter Realistically, what kind of performance gains are going to be seen here?
AFAICT any gain will be extremely minimal and honestly I don't see it as a good reason to ship the extra files with a point release. If it's a big win, a minor release makes sense, but something incredibly minor like this..

[westonruter]

@dd32 I agree the performance gains will be very minor, but it is still a defect. I think the semantics are changing for what “minor” release means this year. If the patch isn't related to a major feature change, then it seems like this is now appropriate for a minor release, whereas previously it would have been deferred to the next scheduled major release. Since major releases aren't scheduled now, I think fixes for defects should continue to roll into minor releases, even when they are't fixed-major ones for the most recent release. I think too that we'd want to avoid letting trunk diverge too far from the latest release as it will make doing minor releases more and more difficult to cherry-pick patches. /cc @matt

[dd32]

For the record; you're arguing over a single postmeta query accounting for a tiny percentage of a pageload. If you feel that strongly. Sure.

[dd32]

In 39692:

Customizer: Don't query for postmeta for Custom CSS (for not-current-themes) and Customizer Changeset posts.

Props dlh.
Fixes #39194.

[dd32]

In 39693:

Customizer: Don't query for postmeta for Custom CSS (for not-current-themes) and Customizer Changeset posts.

Props dlh.
Merges [39692] to the 4.7 branch.
Fixes #39194.