Kirki: Repeater field with transport postMessage causes error

[peterigz]

Issue description:

If you use a repeater field with the transport set to "postMessage" then the javascript crashes during the initialisation of the script, with the error:

customize-controls.js?ver=4.7:56 - Uncaught TypeError: api.state is not a function

This looks like it's because wp.customizer.state hasn't been initialised yet before you call setting.set on the control which fires the callbacks. I think this has only happened since 4.7 so I'm not sure what changed.

I've fixed this by changing the transport to "refresh" before this.setValue( [], false ); is called and then setting it back again after, but it feels a bit hacky to me as I don't really know the code well enough

Version used:

Latest dev version.

[aristath]

I don't get it...
Why would you try to use postMessage on a repeater field??
What were you trying to achieve exactly?

[peterigz]

Same reason as any other field really, to refresh the preview without having to do a reload after making changes, for example, I use a repeater field to add links to a top bar of the header, and also to add add custom fonts to a page and select which css selectors the font applies to. Unless I'm missing something? Why would you not use postMessage?

Just noticed the labels are saying True instead as well for some reason.

[aristath]

I'm assuming you wrote custom JS to take care of the postMessage of that field then? 'Cause it can't be taken care of automatically!

[peterigz]

No, just the standard way in php with selective refresh and add_partial:

$wp_customize->selective_refresh->add_partial( 'custom_scss_settings', array(
    'selector' => '#swish-customerizer-css',
    'settings' => array( 'interactive_color',
                         'header_color',
                         'footer_color',
                         'topbar_color',
                         'bottombar_color',
                         'primary_color',
                         'background_color',
                         'content_background',
                         'navigation_navbar_background',
                         'navigation_submenu_background',
                         'navigation_sticky_menu_background',
                         'navigation_drop_down_button',
                         'shadow_depth',
                         'custom_fonts'),
    'render_callback' => 'swish_preview_customizer_css',
    'fallback_refresh' => false
) );

custom_fonts is the repeater field in above code. Repeater just extends a customizer control so I guess the js is already built in for that. It's always worked really well :)

[aristath]

oh right!!! I forgot all about partial refreshes...
Marked this as a bug, will be fixed as soon as have some time to look into it a bit

[peterigz]

I was starting to question myself, thought maybe I was doing things back to front ;) Thanks for looking into it.

[geocef]

I am having this same problem with REPEATER field and also SORTABLE field when set to PostMessage, after I upgraded my site to wordpress 4.7

@ Peterigz:
You said

"... I've fixed this by changing the transport to "refresh" before this.setValue( [], false ); is called and then setting it back again ..."

Can u please explain into detail how u did it.

[aristath]

until this is fixed, repeater fields will be forcing the use of refresh.
I know this is not a solution, but at least nobody else will get JS errors until we manage to figure this one out.

[maxviewup]

I am using the stable version and it still doesn't force refresh (i'm adding via ['partial_refresh'] argument)

[aristath]

@maxviewup for the time being please use 'transport' => 'refresh'.
The current implementation of repeater controls does not allow us to properly implement postMessage or partial-refreshes.
In order for these to be supported, the whole controls implementation has to be rewritten - and that has already began on a separate branch.
This will be fixed in version 3.1, but until then you will have to use the refresh method with repeaters.