Changes made in the Customizer are not being logged

[frankiejarrett]

After clicking Save & Publish in the Customizer no records are being logged by Stream for changes that were performed.

We'll need to improve the following connectors so that these changes are always tracked:

• Widgets (Revamp widget connector #391)
• Menus
• Settings

/cc @westonruter

[westonruter]

I'm your man!

[frankiejarrett]

😍 !!!

[powelski]

@fjarrett @westonruter I'm on a good way to complete this. What do you guys think about the Context here? Is it better to use Customizer context or the context of particular option that has been changed, for example General for Site Title etc.?

[westonruter]

Yeah, what if the title for the Customizer Section was used for the context? Or maybe it would beed to be "Customizer: Section Title"?

[frankiejarrett]

@powelski @westonruter Not sure we need to be creating any unique contexts for the Customizer, the contexts for each field already exist in their respective connectors (Settings, Widgets, Menus).

We could just add a stream_meta value indicating that the action was performed in the Customizer, so then the summary could be altered. For example:

Then this could still be queried easily using the keyword search, without losing the appropriate connector/context assignment: wp-admin/admin.php?search=customizer&page=wp_stream

[westonruter]

Good idea. It is not really important that it was edited in the Customizer anyway. It's a “by the way” piece of information.

[powelski]

@fjarrett @westonruter It might be a problem to know the context from option name alone. I thought there will access from customizer_save action to globals $whitelist_options and $new_whitelist_options, but there is not. They are loaded in /wp-admin/options.php.

Ideas?

[westonruter]

@powelski what are you trying to look up? I realize that you may have the same problem with customizer controls as you faced when tracking changes to options, as customizer controls are just wrappers around options. One customizer control, in fact, may have multiple settings (options) associated with it, so we wouldn't be able to use the control really to discern what the setting's label is.

In terms of the customizer sections, however, this should be possible. When the customize_save action happens, you can loop over all of the registered controls and grab the customizer section that each is associated with, and the settings (options) that are associated with that control. The title for this section could be used as part of the summary.

[powelski]

@westonruter I'm not sure if I was clear enough. I was talking about context of the option. Like context for Site Title option is General. Those can be found in $new_whitelist_options global, but customizer.php saves changes with Ajax and no globals are available from there.

[powelski]

@westonruter Up :)

[westonruter]

@powelski sorry I've not been able to carve out time to check this out further yet.

[westonruter]

I've been diving into Customizer integration (specifically for widgets) in #391.

So the reason why $new_whitelist_options isn't defined yet is because the register_setting() calls haven't happened. One hack would be to cache the $new_whitelist_options in an option when the user is browsing around the admin. Upon wp_shutdown if there is a $new_whitelist_options which has options which don't already exist in the cached new_whitelist_options, then you could merge them on top and then re-save the cached options. Then when the Ajax request happens, you could access the cached options instead of accessing the $new_whitelist_options global variable.

I believe that the cache would always get primed because /wp-admin/customize.php would result in the register_settings() calls happening before the user ever hits to Save the settings.

[westonruter]

I think this was closed accidentally.

[westonruter]

#391 didn't actually address the changing all settings in the customizer, just the ones for widgets. I think that comment was a carry-over from when the PR was a WIP.

[lukecarbis]

@westonruter This thread is pretty old, but it's still an issue.

Would you have time to look into this? Or could you recommend a place to start?

[westonruter]

@lukecarbis hey, I don't have time to look into it, but I do have a recommended starting place:

The customize_save_{$id_base} action fires for each setting that gets saved. It's unfortunate actually that the action has this dynamic portion, but what you can do is hook into the global customize_save action which actually should be called customize_save_before, and you can then iterate over all of the settings to add the necessary actions for Stream. For instance:

<?php
add_action( 'customize_save', function ( \WP_Customize_Manager $wp_customize ) {

    $actions_added = array();

    foreach ( $wp_customize->settings() as $setting ) {
        /** @var \WP_Customize_Setting $setting */
        $id_base = strtok( $setting->id, '[' );
        if ( isset( $actions_added[ $id_base ] ) ) {
            continue;
        }

        add_action( "customize_save_{$id_base}", function( \WP_Customize_Setting $setting ) {
            // @todo Now log the Stream action here.
            /*
             * Obtaining the name for the Stream action will be a bit tricky, and will
             * not be bulletproof. Basically what you have to do is iterate over
             * $wp_customize->controls() and try to find a control that is associated
             * with this $setting. Then you can try to use $control->label. Beware,
             * however, that a control can be associated with multiple settings.
             */
        } );

        $actions_added[ $id_base ] = true;
    }
}, 100 );