Make WordPress Core

Opened 9 years ago

Last modified 7 years ago

#29948 new enhancement

Use contextual controls (active_callback) API for conditionally-displayed core contextual controls

Reported by: celloexpressions's profile celloexpressions Owned by:
Milestone: Future Release Priority: lowest
Severity: normal Version: 4.0
Component: Customize Keywords: needs-patch
Focuses: Cc:


See wp-admin/js/customize-controls.js, near the bottom. Rather than doing some unstructured JS to show/hide controls based on the values of other settings, this should use custom callbacks for the active_callback argument when adding the control (in php).

Change History (11)

#1 @westonruter
9 years ago

You're referring to this code?

                // Control visibility for default controls
                        'background_image': {
                                controls: [ 'background_repeat', 'background_position_x', 'background_attachment' ],
                                callback: function( to ) { return !! to; }
                        'show_on_front': {
                                controls: [ 'page_on_front', 'page_for_posts' ],
                                callback: function( to ) { return 'page' === to; }
                        'header_textcolor': {
                                controls: [ 'header_textcolor' ],
                                callback: function( to ) { return 'blank' !== to; }
                }, function( settingId, o ) {
                        api( settingId, function( setting ) {
                                $.each( o.controls, function( i, controlId ) {
                                        api.control( controlId, function( control ) {
                                                var visibility = function( to ) {
                                                        control.container.toggle( o.callback( to ) );

                                                visibility( setting.get() );
                                                setting.bind( visibility );

#2 @celloexpressions
9 years ago

Yes, although I didn't look at it particularly closely. Maybe it makes more sense to keep it separate, but it seemed like it would be better to move it (and also to make those controls less tightly coupled with core, so that they can be understood as examples for themes and plugins).

#3 @celloexpressions
9 years ago

That being said, it wouldn't be instant based on the current methods, so maybe that isn't the best approach. We may need an improved API for conditional controls that is all-js, but doesn't require as much custom code for individual controls implementing it themselves.

This ticket was mentioned in Slack in #core-customize by valendesigns. View the logs.

9 years ago

#5 @celloexpressions
9 years ago

  • Priority changed from normal to lowest

#6 @valendesigns
9 years ago

I like this idea, though we need to discuss implementation when time permits and before a patch is started.

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.

8 years ago

#8 @netweb
8 years ago

Adding the chat note by @ celloexpressions in Slack

"#33420, #33428 and #33434 are all duplicates. Testing, looks like the code that toggles those is conflicting with their active states. Best solution is probably to do #29948, but we likely need to figure something else out for 4.3.1. Looks like changing static front page also re-calculates the top position of the section (incorrectly),”

Related: #33420, #33428 and #33434

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.

7 years ago

#11 @westonruter
7 years ago

  • Milestone changed from Awaiting Review to Future Release
Note: See TracTickets for help on using tickets.