#30235 closed defect (bug) (fixed)
Improve ability to filter active state for widget area Customizer sections
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 4.1 | Priority: | normal |
Severity: | normal | Version: | 4.1 |
Component: | Customize | Keywords: | has-patch |
Focuses: | javascript | Cc: |
Description (last modified by )
Currently in trunk, to mark a Customizer section representing a widget area (sidebar) you have to supply two separate filters instead of one:
<?php /** * Prevent the second widget area (sidebar) from being displayed in the Customizer. * * @param bool $active * @param WP_Customize_Section $section * @return bool */ function force_hide_second_widget_area_customize_section( $active, $section ) { if ( 'sidebar-widgets-sidebar-2' === $section->id ) { $active = false; } return $active; } add_filter( 'customize_section_active', 'force_hide_second_widget_area_customize_section', 10, 2 ); /** * Prevent the second widget area (sidebar) from being displayed in the Customizer. * * @param bool $active * @param WP_Customize_Control $control * @return bool */ function force_hide_second_widget_area_customize_control( $active, $control ) { if ( 'sidebars_widgets[sidebar-2]' === $control->id ) { $active = false; } return $active; } add_filter( 'customize_control_active', 'force_hide_second_widget_area_customize_control', 10, 2 );
Only the first one really should be needed, but the SidebarControl
currently syncs its active
state to the containing section:
// Update the model with whether or not the sidebar is rendered self.active.bind( function ( active ) { registeredSidebar.set( 'is_rendered', active ); api.section( self.section.get() ).active( active ); } );
This was done in 4.0 because there was no active
state for sections, since there were no models for sections at all. But now that there are models for sections (and panels) we should allow just filtering of customize_section_active
to be able to inactivate a section.
Initially discussed at https://make.wordpress.org/core/2014/10/27/toward-a-complete-javascript-api-for-the-customizer/#comment-20619
Attachments (2)
Change History (13)
#5
@
10 years ago
- Keywords has-patch added; needs-patch removed
- Owner set to ocean90
- Status changed from new to reviewing
In 30235.diff (c91db4dd
):
- Mark panels, sections, controls as active if preview explicitly indicates.
- Introduce
WP_Customize_Sidebar_Section
PHP class, andSidebarSection
JS class - Move logic for determining whether a sidebar section is active from the
SidebarControl
toSidebarSection
.
Filtering the active
state of a Sidebar section can be handled with a filter like this (improved version from above, as note the sidebar_id
param):
<?php /** * Prevent the second widget area (sidebar) from being displayed in the Customizer. * * @param bool $active * @param WP_Customize_Section $section * * @return bool */ function force_hide_second_widget_area_customize_section( $active, $section ) { if ( $section instanceof WP_Customize_Sidebar_Section && 'sidebar-2' === $section->sidebar_id ) { $active = false; } return $active; } add_filter( 'customize_section_active', 'force_hide_second_widget_area_customize_section', 10, 2 );
#6
follow-up:
↓ 7
@
10 years ago
The change in src/wp-admin/js/customize-controls.js
hides my test panel:
add_action( 'customize_register', function() { global $wp_customize; $wp_customize->add_panel( 'foo', array( 'title' => 'Foo', 'capability' => 'customize', // 'priority' => 1, ) ); $wp_customize->add_section( 'bar', array( 'title' => 'Bar', 'capability' => 'edit_posts', 'panel' => 'foo' ) ); $wp_customize->add_setting( 'foobar[foo]', array( 'default' => 'Foo', 'capability' => 'edit_posts', 'type' => 'option', )); $wp_customize->add_control('foobar', array( 'label' => 'Foobar', 'section' => 'bar', 'settings' => 'foobar[foo]', 'type' => 'textarea', )); });
Can we fix this or shoudl we exclude it from the patch for now?
#7
in reply to:
↑ 6
@
10 years ago
Replying to ocean90:
Can we fix this or shoudl we exclude it from the patch for now?
Strange. For some reason the section is not getting registered in the preview and so it is not iterated over inside of WP_Customize_Manager::customize_preview_settings()
:
foreach ( $this->sections as $id => $section ) {
$settings['activeSections'][ $id ] = $section->active();
}
Because the panel's sole section is then inactive, the panel then automatically is considered inactive as well (contextually inactive). It's strange because the control and the panel both are being picked up. It's just the section that is not.
I'm looking into why.
#8
@
10 years ago
Got it. In 30235.2.diff it also loops over the sections associated with each panel, since such panels no longer are located in the $wp_customize->sections
array anymore. This could be a point of confusion when working with the PHP API and the JS API, since in the latter the sections are all located in the same array but in the former they are not.
#10
@
10 years ago
@brianfeister: The fixes for this ticket caused a regression. Could you verify that my new patch to fix the regression does not undo any of the original fixes for this ticket? See https://core.trac.wordpress.org/ticket/30378#comment:2
https://github.com/xwpco/wordpress-develop/pull/52