active_callback: Maximum call stack size exceeded

[JimmyAppelt]

Issue description:

Maximum call stack size exceeded at Object.checkCondition (field-dependencies.js?ver=3.0.33:103)

Version used:

3.0.33

Using theme_mods or options?

theme_mods

Code to reproduce the issue (config + field(s))

$dont_display = '__return_false';

'active_callback' => array(
	array(
		'setting'  => 'other_setting',
		'operator' => '==',
		'value'    => true,
	),
	$dont_display 
),

ex. __return_false worked fine like this in a previous version I worked with (3.0.15)

If this behavior is changed, how should we approach multiple active_callbacks which are not depending on an option?

[aristath]

ex. __return_false worked fine like this in a previous version I worked with (3.0.15)

I don't believe this was ever working in previous versions if combined with other items... It can be either a valid callback, or an array or arguments. But not a combo of the 2... Can you please confirm that you had that working on a previous version when using both a callback and an array of arguments?
If yes then we'll need to backtrack this and figure out what changed

[JimmyAppelt]

Hi @aristath

Yes, I can confirm this was working, I have a theme project which includes 3.0.15 (within the project), where we configured it like this.

We could manage when returning a simple boolean too, instead of a PHP function, but that isn't working either.

$conditional_display = x ? true : false;

'active_callback' => array(
	array(
		'setting'  => 'other_setting',
		'operator' => '==',
		'value'    => true,
	),
	$conditional_display 
),

[aristath]

I can confirm that this no longer works. In older versions there was a PHP implementation that was handling all field dependencies. However that implementation had a lot of bugs and was causing a lot of issues when using postMessage or when the conditions were too complicated, resulting in server timeouts etc.
That implementation has been removed since v3.0.15, but almost nobody uses mixed PHP conditions and field dependencies so this error was not discovered until now.

The bad news is that we can't really make this work the way it did unless we revert to the previous buggy implementation.
We could make this work, but only if we dropped support for PHP 5.2 since it will require using an anonymous function, but that's easier said than done since there are hundreds of themes out there that use Kirki and we can't drop support for PHP 5.2 without a proper plan.

The good news is that I just pushed a commit that will not throw any errors. However, it does that by removing the extra PHP conditions and only keep the field dependencies since these are implemented via JS. This fix will be included in v3.0.34 which will be released soon.

Alternative solutions:
You could change the active_callback in your theme to use a valid PHP callback.
If you're using PHP 5.3+ you can do it like this using an anonymous function:

'active_callback' => function() {
	$dependency_option = get_theme_mod( 'other_setting', true );
	$other_condition   = is_singular();
	if ( true === $dependency_option && $other_condition ) {
		return true;
	}
	return false;
},

If for some reason you need to keep compatibility with PHP 5.2 (which is the unfortunate case for Kirki) then you can just create a function like this:

function custom_function_check_dependency() {
	$dependency_option = get_theme_mod( 'other_setting', true );
	$other_condition   = is_singular();
	if ( true === $dependency_option && $other_condition ) {
		return true;
	}
	return false;
}

and then use that function as a callback:

'active_callback' => 'custom_function_check_dependency',

[JimmyAppelt]

Thanks, we'll see how we can change this

The good news is that I just pushed a commit that will not throw any errors.

Errors are a good thing, otherwise we would not know what went/is wrong 🙂

[aristath]

Errors are a good thing, otherwise we would not know what went/is wrong 🙂

True... but if this was a theme that's live and used by a couple hundred users, then quite a few sites would be unable to access the customizer.
So in this case I think it's preferable to bypass the error. Otherwise people will be unable to use the customizer in their any sites 😉