WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#39843 closed enhancement (wontfix)

Allow a control to be displayed in multiple sections

Reported by: nikeo Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.7.2
Component: Customize Keywords:
Focuses: Cc:

Description

With the current customize API, a control can be assigned to only one section.

The customization experience could be improved if a control could show up in multiple sections. Typically when the customizer has a lot of settings in many sections, it would partially solve the problem to have to navigate back and forth in the sections and panels.

Theme authors need of coursee to organize their controls the most convenient and logical way. But they are cases when a setting is global by nature, and can be optionally setup in various location of the page.

Use case with the social links icons :
I have set up my social links in the Social Links section, which is located in the Global Settings panel. It make sense to define the social links in Global Settings panel because they can be displayed in several locations of the website : header, top of sidebars and footer. The visibility of the social links in the page is set with a checkbox control for each location. I uncheck the control "Social links in header".

Later, I go back to the customizer, and now I want to design my header. To do that I navigate to the Header panel > Header Design section. I would make sense to also see there the "Social links in header" check box.

This "ubiquity" behaviour of a control is illustrated in the gif. In the example, the control "Social links in header" has been assigned to both the Social Links and the Header Design section.

From a code standpoint, a possible approach is to add a new argument when declaring the customizer control. It can be an array with the section id and the priority. In the customizer js control panel, the section expansion / collapse will be listened to, and will trigger a control move back and forth when relevant with api.control('control_id').section( 'new_section_id').

Attachments (1)

control_ubiquity.gif (690.8 KB) - added by nikeo 3 years ago.

Download all attachments as: .zip

Change History (3)

#1 @westonruter
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

@nikeo thanks for the suggestion, but core supports adding a controls for the same setting to multiple sections already. You just have to add the control to each section you desire. I don't think that there is a need for a control to support multiple sections at once, since it is almost just as easy to just add multiple controls with the same configurations aside from the section. Trying to add support for a multi-section control would have very little gain for the headaches involved in the API change.

For example, given the current Site Title control:

<?php
$wp_customize->add_control( 'blogname', array(
        'label'      => __( 'Site Title' ),
        'section'    => 'title_tagline',
) );

To add an additional control that also manipulates the blogname setting but appears in the colors section in addition to the title_tagline section, all that is required is:

<?php
$wp_customize->add_control( 'blogname_in_colors_section', array(
        'label'      => __( 'Site Title' ),
        'section'    => 'colors',
        'settings'   => 'blogname',
) );

In other words, since the control ID is no longer one-to-one with the control's setting ID, then you just have to give a unique control ID and explicitly specify the settings

#2 @nikeo
3 years ago

@westonruter yes, 2 different controls assigned to the same setting would do the same job. I agree, your solution is better. It adds a new control, but we can live with it. The most important is that it is simpler to implement and using the existing core.

I knew it was something doable but I honestly totally did not think about it as a possible solution to solve this problem! This is probably because I am to much used to work with a one to one control - setting pair when developing in the js customize api.

Thanks for this detailed feedback :)

Note: See TracTickets for help on using tickets.