WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 21 months ago

#30251 closed defect (bug) (fixed)

Customizer inconsistent contextual behavior

Reported by: dgwyer Owned by: ocean90
Milestone: 4.1 Priority: normal
Severity: normal Version: 4.1
Component: Customize Keywords: has-patch commit
Focuses: javascript Cc:

Description

When adding more than one contextual customizer control with I'm seeing inconsistent behavior.

For example, I'm using the bare bones theme created by Otto available here:
http://ottopress.com/2012/theme-customizer-part-deux-getting-rid-of-options-pages/

All I've done in functions.php is to add two 'active_callback' lines, one for each customizer control:

	'active_callback' => '__return_false'
	'active_callback' => '__return_true'

Using these core WordPress callbacks only one of the controls should be visible but when the customizer loads both controls are visible.

If you remove one of the controls in functions.php then the remaining control is visible (or not) depending on the contextual callback return value, as expected.

Note: In full themes this issue seems to be mainly when the customizer first loads. When clicking links inside the customizer preview window the customizer controls seem to respect their contextual settings, apart from the initial load.

Attachments (3)

contextual_themedemo.zip (2.1 KB) - added by dgwyer 3 years ago.
Otto's bare bones theme with the contextual behavior added
30251.diff (2.4 KB) - added by westonruter 3 years ago.
https://github.com/xwp/wordpress-develop/pull/53
is_page_error.png (258.2 KB) - added by dgwyer 3 years ago.

Download all attachments as: .zip

Change History (13)

@dgwyer
3 years ago

Otto's bare bones theme with the contextual behavior added

#1 @westonruter
3 years ago

Are you experiencing this problem in trunk or in 4.0?

#2 @dgwyer
3 years ago

In trunk.

#3 @westonruter
3 years ago

  • Focuses javascript added
  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 4.1
  • Owner set to westonruter
  • Status changed from new to assigned

I'm seeing the same thing. Investigating.

#4 @westonruter
3 years ago

  • Keywords has-patch added; needs-patch removed
  • Owner changed from westonruter to ocean90
  • Status changed from assigned to reviewing

In 30251.diff:

  • Use jQuery.fn.toggle() instead of slideUp/slideDown if panel/section/control is not inserted into DOM yet.

Made an improvement to the sample theme to help demonstrate toggling the control from inactive to active, and back again: https://gist.github.com/westonruter/2180ab8624a210e6eefb/revisions

The problem is that jQuery seems to do nothing when calling slideUp on elements that are not inserted into the DOM yet, which can now be the case now when first loading the Customizer as the panels, sections, controls get dynamically inserted.

#5 follow-up: @dgwyer
3 years ago

That seems to fix the issue on initial customizer load.

I came across another issue just now when using 'is_page' as the 'active_callback' value. This is nothing to do with your patch though as it happens regardless of whether the patch is applied or not.

I'm using a clean install of WordPress trunk with no custom added content or plugins active. The sample theme added above is the active theme.

Steps to reproduce:

  1. Change the 'active_callback' value for one of the controls in functions.php to 'is_page'.
  2. View the 'Sample Page' included with the default WordPress installation on the front end.
  3. Select 'Customize' from the WordPress toolbar.
  4. See the screenshot for the resulting errors.

@dgwyer
3 years ago

#6 in reply to: ↑ 5 @westonruter
3 years ago

Replying to dgwyer:

That seems to fix the issue on initial customizer load.

I came across another issue just now when using 'is_page' as the 'active_callback' value. This is nothing to do with your patch though as it happens regardless of whether the patch is applied or not.

OK, the problem is that $wp_customize is passed as the first argument to the active_callback. The is_page function expects a page ID or string slug. So what you should do instead is something to the effect of:

    'active_callback' => function () { return is_page(); }

#7 @dgwyer
3 years ago

Thanks for clarifying. It's not very intuitive though for functions like is_page() that have optional parameters, as you'd expect 'active_callback' => 'is_page' to work just like 'active_callback' => 'is_front_page'. The only difference being is_front_page() doesn't take any parameters and is_page() takes optional parameters. I'll just have to remember to check parameters or use anonymous functions!

I tested your patch on the full theme I originally had issues with. My specific use case is only showing certain customizer controls depending on page layout (1, 2, or 3 columns) and the patch seems to fix all issues. Everything is working nicely now.

Thanks for patching this issue so quickly. Hopefully it can be added to core for 4.1.

#8 @westonruter
3 years ago

  • Keywords commit added

#9 @ocean90
3 years ago

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

In 30307:

Customizer: Use jQuery.fn.toggle() instead of slideUp/slideDown if panel/section/control is not inserted into DOM yet.

jQuery does nothing when calling slideUp on elements that are not inserted into the DOM yet, which can now be the case now when first loading the Customizer as the panels, sections and controls get dynamically inserted, see #28709.

props westonruter.
fixes #30251.

#10 @westonruter
21 months ago

Note #33509 identifies an issue with jQuery.contains() as used in the committed patch.

Note: See TracTickets for help on using tickets.