WordPress.org

Make WordPress Core

Opened 7 months ago

Closed 6 months ago

Last modified 6 months ago

#39194 closed defect (bug) (fixed)

Invalid parameters in Custom CSS and Changeset queries

Reported by: dlh Owned by: dd32
Milestone: 4.7.1 Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords: has-patch
Focuses: Cc:

Description

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.)

Attachments (2)

39194.2.diff (733 bytes) - added by dlh 7 months ago.
"Side note" patch
39194.diff (1.1 KB) - added by dlh 7 months ago.

Download all attachments as: .zip

Change History (16)

@dlh
7 months ago

"Side note" patch

@dlh
7 months ago

This ticket was mentioned in Slack in #core-customize by celloexpressions. View the logs.


7 months ago

#2 @celloexpressions
7 months ago

  • Keywords has-patch needs-testing added
  • Milestone changed from Awaiting Review to 4.7.1

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

#3 @dd32
6 months ago

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

#4 follow-up: @westonruter
6 months ago

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

#5 in reply to: ↑ 4 @boonebgorges
6 months ago

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.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


6 months ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


6 months ago

#8 @jbpaul17
6 months ago

  • Milestone changed from 4.7.1 to 4.8
  • Owner set to dd32
  • Status changed from new to assigned

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

#9 @westonruter
6 months ago

  • Milestone changed from 4.8 to 4.7.2

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

#10 @dd32
6 months ago

@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..

#11 @westonruter
6 months ago

@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

#12 @dd32
6 months ago

  • Keywords needs-testing removed
  • Milestone changed from 4.7.2 to 4.7.1

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

Last edited 6 months ago by dd32 (previous) (diff)

#13 @dd32
6 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 39692:

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

Props dlh.
Fixes #39194.

#14 @dd32
6 months ago

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.

Note: See TracTickets for help on using tickets.