Customizer inconsistent contextual behavior

[dgwyer]

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.

[dgwyer]

Otto's bare bones theme with the contextual behavior added

[westonruter]

Are you experiencing this problem in trunk or in 4.0?

[dgwyer]

In trunk.

[westonruter]

I'm seeing the same thing. Investigating.

[westonruter]

​https://github.com/xwp/wordpress-develop/pull/53

[westonruter]

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.

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

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.

[westonruter]

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(); }

[dgwyer]

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.

[ocean90]

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.

[westonruter]

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