htmlburger / carbon-fields

WordPress Custom Fields Library ✨
https://carbonfields.net/
Other
1.38k stars 244 forks source link

Feature Request: Customizer Containers (Panels) #344

Open dmhendricks opened 7 years ago

dmhendricks commented 7 years ago

There are several Customizer libraries out there, but I haven't see one that is either as robust as Carbon Fields or has active development. The exception is Kirki, but I like working with Carbon Fields better because I'm used to it and because it is so easy to work with. EDIT: Also, Kirki isn't ideal with Composer and you have to delete the "readme.txt" that it pulls in composer.json because the WP.org repo will throw a fit (if I remember correctly).

It would be great if I could add a Container/Panel to Customizer as I can add a theme_options settings page. "One Framework to Rule Them All™"

I imagine that Customizer presents several challenges given its support for realtime/visual frontend updates, so this may not be a realistic request. It would be sweet, though.

Thank you, Daniel

vladcosorg commented 6 years ago

There's Redux framework that's can add the theme options both into the Dashboard and into customizer at the same time. Considering the currently WP team is actively pushing all the themes to move theme options from the Dashboard to Customizer, it might be a useful and timely feature.

By the way, the Customizer can already natively display theme options, carbon options can already be hooked up there.

dmhendricks commented 6 years ago

There was a project where I wanted to use Repeaters/Complex Fields and Customizer options. I was tempted to add both frameworks, but that seemed like unnecessary bloat, so I used the WP native functions for Customizer and Carbon Fields for everything else.

Adding Customizer panel containers with CF fields, in addition to an automatic CSS generation property (and likewise, allow the injection of JS variables and not solely CSS as gravy) would be a killer feature. I'm not aware of a framework that is capable of all of those things plus everything that CF does all-in-one.

Of course, (referencing the examples below) the CSS/JS injection don't necessarily have to be limited to 'customizer' containers - maybe theme_options would be an additional starter candidate, and of course, you could mix ->set_css(), ->set_js() and traditional/non-injected/save-only fields in the same container.

I picture something like:

CSS Example

Container::make( 'customizer', 'myprefix-custom-panel', 'Panel Name' )
    ->add_fields( array(
        Field::make( 'color', 'myprefix_body_background', 'Background Color' )
            ->set_css( 'body { background-color: <%- value %>; }', 'screen' )
    )
);

...would inject something like:

<style type="text/css" media="screen">body { background-color: #1E1E1E; }</style>

(The second ->set_css() parameter, the media type, would be optional - perhaps default to 'all'. If specified and if there are more than one, it would break out and group field value injections by media type.)

JavaScript Example

Container::make( 'customizer', 'myprefix-custom-panel', 'Panel Name' )
    ->set_group_variable( 'myprefix_custom_data' )
    ->add_fields( array(
        Field::make( 'checkbox', 'myprefix_slide_panel', 'Enable Slide Panel' )
            ->set_js( 'enable_slide_panel' ), // This could also be null/true/unset and it would just use the field name
        Field::make( 'text', 'myprefix_max_results', 'Some Sort of Number' )
            ->set_parameter( 'type', 'number' )
            ->set_js( 'max_results' ),
        Field::make( 'checkbox', 'myprefix_enable_warp_drive', 'Some Other Checkbox' )
            ->help_text( 'This value would not be injected - merely saved as usual - since set_js() is not called.' )
    )
);

...would inject something like:

<script>var myprefix_custom_data = JSON.parse( '{ "enable_slide_panel":"yes", "max_results":12 }' );</script>

Then, in my own JavaScripts, I could reference the passed values simply:

if( myprefix_custom_data[ 'enable_slide_panel' ] == 'yes' ) {
    // Perform my custom logic
    // Ideally, I'd prefer if it passed true or false for boolean options, but that's picking nits
}

EPIC :muscle:

(note that this post was not checked for typos or syntax - it's just an example of my thoughts and sometimes my brain throws unhandled exceptions)