0

I am developing a theme that has a lot of theme mods, sections, panels. My issue is that the Customizer loads all of them at once and it can take awhile for it to load. Also, I would really like to load only the settings, sections needed for the page I am currently editing.

I've been looking for some filters in the WP_Customize_Manager but I can't find any that would modify the sections, panels, settings, controls proprieties or the methods they are used into.

At this point I am getting the page id by adding it to the Customizer url, something like wp-admin/customize.php?url=pageurl&apageid=700

Based on that page id I would like to register the needed sections and settings, and remove the rest.

Just an example, did this with panels, controls, sections too:

function test_reg( $wp_customize ) {
    $currentID = isset( $_GET['apageid'] ) ? absint( $_GET['apageid'] ) : '';

    // tmpl_ids() returns an ids array of all the pages that use a certain page template
    if( in_array( $currentID, tmpl_ids() ) {
        $custom_settings = array( 
            'custom_setting_' . $currentID, 
        );

        foreach( $custom_settings as $val ) {
            ... register the setting here.
        }

        foreach( $wp_customize->settings() as $setting ) {
            if( ! in_array( $setting->id, $custom_settings ) ) {
                $wp_customize->remove_setting( $setting->id );
            }
        }
    }
}
add_action( 'customize_register', 'test_reg', 999 );

This will remove the settings, but it will not work for the previewer customize_preview_settings, which will output all of them.

Anyway, any idea how to do this properly? Thank you!

1 Answer 1

4

The most robust way to do this is to do JavaScript-based instantiation of the sections, controls, and settings dynamically in response to the URL being previewed. Since you can navigate around the site in the preview, this will ensure that the post/page-specific sections and controls will be created as you need them when you navigate around the site. This depends on the preview communicating to the controls pane parent window with the URL being previewed (and the queried post ID). Both of these are implemented in the Customize Posts feature plugin, and more details on the message passing from the preview can be seen in #36582.

Nevertheless, since you're probably looking for a more static PHP solution, the easiest way to ensure both the controls window and the preview window are able to see the same post ID is to not use a custom query var like apageid but rather to use the actual url parameter that is used to tell the customizer which URL to load into the preview. For example when you are on the frontend on a page or singular post and you click Customize, the url param will be the permalink. With that in hand, you can then read from the url param and pass it through url_to_postid() to get the post ID.

There is one other piece needed here and that is to implement dynamic settings. Because a setting is dynamically created in PHP based on whether or not you are on a given page, once you try updating or publishing the changeset you'll see an error message about the setting not being recognized. By implementing dynamic settings you can tell PHP how to recognize settings based on patterns in their IDs and register them just in time.

Here's a full working example plugin which adds a section for the initially-loaded loaded post and adds a checkbox control for indicating whether the post content should be made all uppercase or not: https://gist.github.com/westonruter/9e9510c7f57dfbd37eb8c0162b971aa2

You may also want to consider checking out Resetting the Customizer to a Blank Slate.

13
  • Very interesting. IMHO this technique worth some more highlighting. Have some question about the code, but will ask it on the gist. Feb 21, 2017 at 19:51
  • @MarkKaplun I'll reply here because comments on Gists don't trigger notifications, unfortunately. The reason why get_queried_object_id() cannot be used in this example is because customize_register triggers before the global $wp_query is initialized (at the wp action). So that is why the example does url_to_postid() on the REQUEST_URI when in the customizer preview context as opposed to the admin controls/pane context. Feb 21, 2017 at 20:26
  • @MarkKaplun Scratch that. I just refactored the plugin to do late-registration of the settings so that the queried object and the previewed URL are available. Feb 21, 2017 at 20:52
  • additional virtual +1 for that change ;) Feb 21, 2017 at 21:03
  • 1
    The Customize Posts plugins has lots of examples. There is also a single-file extension to that plugin that has examples: gist.github.com/westonruter/f8473159e48fbacbef9dcd6498155846 Sep 8, 2017 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.