WP Customizer stopped working

[izlietnes]

After last update to Kirki v3.0.27 the WP Customize page stopped working (not loading the page and sidebar tools, but the customize framework is shown)

When I disable the Kirki plugin, the customize page is working again thou many customizing options are gone.

I'm using Unero theme from Drfuri & WPBakery.

I haven't touched any files that would ruin Kirki plugin's functionality.

[izlietnes]

Looks like this when the updated version is enabled.

[asilcetin]

Can you open the developer tools on chrome and paste a screenshot of console tab if you see any errors there?

[izlietnes]

[asilcetin]

I've been trying hard to reproduce this error, since it's clearly related to e64b116, however even after making a fresh instance with the latest kirki version and trying out different combinations of select field inside repeaters I couldn't get this error.

Can you maybe share the config of your fields? Especially the select fields defined inside repeaters would be related. And maybe you can edit kirki/controls/php/class-kirki-control-repeater.php and add the following code at line 304:

<# console.log(field); #>

Then please paste here the output of this log from developer tools > console tab.

[asilcetin]

OK, I think I know what's going on here.

When you create a new select field in a repeater without any default values and save it without any selections field.default is [""]. In this case field.default.indexOf(i) is -1, as it should be. Then you select some values and save, then your field.default is ["1"] or ["1", "2"] or something like that and field.default.indexOf(i) will work again as expected.

However if you somehow manage to define your field.default as an integer (which cannot be achieved with a fresh theme install, but you can maybe have a previously saved integer value for this field from a different control with the same settings name) then the field.default.indexOf(i) will throw this error because indexOf() won't work with an integer.

To avoid this error we can first check if field.default is an array.

Option 1:
if ( field.default instanceof Array && field.default.indexOf(i) !== -1 )
This will return false both when field.default is an integer or undefined, as we would want.
Note: indexOf() isn't supported on IE8 and below.

Option 2:
if ( jQuery.inArray(i, field.default) !== -1 )
If we're willing to use a jQuery function here, then this may be a good option since it'll return false both when field.default is an integer or undefined and would work on vintage browsers.

What do you think @aristath?

[izlietnes]

Hi, Asil,

Thank You for helping to find a solution.
I've added the code <# console.log(field); #> in class-kirki-control-repeater.php and console shows the following:

[izlietnes]

And I apoligize - I'm a complete dum dum about coding ;)

[izlietnes]

So It would be completely ok If you say i screwed up something & it's no problem in Kirki's plug-in

[izlietnes]

I just did a rollback to v3.0.25 and the customizer is working again, without errors

[asilcetin]

Thanks for the screenshot and reporting, no it's not your fault.

It's exactly what I expected, just look at the default value right before the Uncaught TypeError where it says "default: 1", which is an integer. It should have been default: ["1"], it's obviously a wrong type saved in the database.

For now a rollback to the previous version would solve the issue for you. And we should change the code in kirki to avoid such an error as I described in my previous comment. I'll make a new pull request soon.

[izlietnes]

Now I understand.
Thanks!

[Spolaa]

A temporary solution could be this. The problem is that filed.default is an integer.
class-kirki-control-repeater.php on line 259 add follow line:
<# field.default = field.default? field.default.toString (): ''; #>
The problem is that in turn, another error is generated: Maximum call stack size exceeded.

[aristath]

Thank you all for the detailed debug info!
I'm marking this as a bug and it will be fixed in v3.0.28 as soon as I get some free time to push the changes.
Of course if someone can submit a PR that's always more than welcomed 👍

[aristath]

Since there's no problem using jQuery in there I pushed the 2nd solution from #1879 (comment)
This will be included in v3.0.28. 👍