WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 5 weeks ago

#21627 new enhancement

Filter for custom-background CSS selector

Reported by: Horttcore Owned by: Horttcore
Milestone: Future Release Priority: low
Severity: minor Version: 3.4.1
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description

There should be an easier way for changing the css selector from body to html or any other then making your own callback.

Attachments (5)

theme.diff (426 bytes) - added by Horttcore 3 years ago.
Filter applied to css selector
21627.diff (848 bytes) - added by westonruter 11 months ago.
Use theme feature attribute instead of filter for selector
21627.3.patch (4.1 KB) - added by peterwilsoncc 5 weeks ago.
21627.4.diff (3.6 KB) - added by peterwilsoncc 5 weeks ago.
21627.5.diff (4.6 KB) - added by peterwilsoncc 5 weeks ago.
Pass settings using WP_Customize_Manager::customize_preview_settings

Download all attachments as: .zip

Change History (21)

@Horttcore3 years ago

Filter applied to css selector

comment:1 @nacin3 years ago

Why might modifying this selector be necessary?

comment:2 @Horttcore3 years ago

With the filter you could set it to any other element i.e. html which could be better for the theme.

Here is a sample code:

body {
   margin: auto;
   width: 965px;
}

With the current selector just a part of the site will have the custom background.
The background should be applied to the highest element in the DOM by default and that would be html.

We could add this filter or just change the selector to the html element.

What do you prefer?

comment:3 @cais3 years ago

  • Cc edward.caissie@… added

comment:4 @rulatir2 years ago

Very much seconded.

comment:5 @ocean9021 months ago

#25379 was marked as a duplicate.

comment:6 @ocean9021 months ago

Having a filter in a custom callback doesn't sound like a good plan, since we cannot ensure that plugin/theme authors are including the filter in a custom callback too.

comment:7 @dreamwhisper20 months ago

  • Cc dreamwhisper added

comment:8 @nacin16 months ago

  • Component changed from Themes to Appearance

@westonruter11 months ago

Use theme feature attribute instead of filter for selector

comment:9 @westonruter11 months ago

  • Milestone changed from Awaiting Review to Future Release

Replying to ocean90:

Having a filter in a custom callback doesn't sound like a good plan, since we cannot ensure that plugin/theme authors are including the filter in a custom callback too.

Right, when the custom-background theme support is added, the theme may supply a customwp-head-callback callback which would not be required to the proposed filter. However, if there was a filter, then themes would have much less cause to have to override wp-head-callback's default callback of _custom_background_cb to begin with. I would imagine that providing a custom callback for wp-head-callback is usually due to a different selector being needed.

As an alternative to providing a filter, there could be a new default element-selector property of the custom-background theme support. A custom theme callback would still need to honor element-selector, but they also have to do this already for background repeats, positions, and attachments. See 21627.diff.

comment:10 @celloexpressions7 months ago

  • Milestone changed from Future Release to 4.1

+1 for 21627.diff.

comment:11 follow-up: @SergeyBiryukov7 months ago

The selector also appears in customize-preview.js. Should it be updated there as well?

comment:12 in reply to: ↑ 11 @celloexpressions7 months ago

  • Keywords needs-patch added; has-patch removed
  • Priority changed from normal to low
  • Severity changed from trivial to minor

Replying to SergeyBiryukov:

The selector also appears in customize-preview.js. Should it be updated there as well?

Yes.

comment:13 @ocean907 months ago

  • Milestone changed from 4.1 to Future Release

@peterwilsoncc5 weeks ago

@peterwilsoncc5 weeks ago

comment:14 follow-up: @peterwilsoncc5 weeks ago

Sorry, ignore .3

21627.4.diff builds on @westonruter's patch to include:

  • customize-preview.js
  • take theme authors preference in get_body_class()

customize-preview.js requires the element be selectable without the class, so I've split the element and the selector into two options applied to the theme-support array.

comment:15 in reply to: ↑ 14 @westonruter5 weeks ago

Replying to peterwilsoncc:

Sorry, ignore .3

21627.4.diff builds on @westonruter's patch to include:

  • customize-preview.js
  • take theme authors preference in get_body_class()

customize-preview.js requires the element be selectable without the class, so I've split the element and the selector into two options applied to the theme-support array.

Thanks, but accessing settings from the parent frame via window.parent._wpCustomizeSettings isn't going to make it into Core. So either you need to use postMessage passing, or export the settings directly into the preview instead via WP_Customize_Manager::customize_preview_settings().

@peterwilsoncc5 weeks ago

Pass settings using WP_Customize_Manager::customize_preview_settings

comment:16 @peterwilsoncc5 weeks ago

Replying to westonruter:

Replying to peterwilsoncc:
So either you need to use postMessage passing, or export the settings directly into the preview instead via WP_Customize_Manager::customize_preview_settings().

Thanks for the feedback, I've updated in 21627.5.diff to use the correct method.

Whilst this code allows theme authors to customise the element and the class, it still enforces the overloaded element.classname selector, is it worth including a third setting and defaulting to the overloaded selector?

Note: See TracTickets for help on using tickets.