Speed Issue in class-wp-customize-setting.php

[wpweaver]

I don't understand the whole algorithm, but class-wp-customize-setting.php has a SERIOUS speed issue using the final protected function multidimensional_replace( $root, $keys, $value ) function.

The problem is related to the total number of options added to the customizer (using 'options' - I did not test using 'theme_mod'.

As the number of options grows, the time to refresh the site page increases, apparently non-linearly.

At some point, the time to process this function takes so long, the process will crash with a PHP execution timeout - 30 seconds on my system. There should be no algorithm, ever, dealing with simple arrays of settings on the order of 1000 or less that takes 30 seconds.

This problem is very simple to reproduce. Create a simple Customizer section with multiple instances of 'checkbox' controls - for example:

$max_items = 600; // vary this - on my system, there is an execution timeout at about 600
$transport = 'refresh';

	for ($i = 0 ; $i < $max_items; $i++) {

		$speedtest_sections['speedtest-general']['options']["speedtest{$i}"] =
		array(
		'setting' => array(
			'sanitize_callback' => 'absint',
			'transport' => $transport,
			),
		'control' => array(
			'label' => "speedtest Control #{$i}",
			'type'  => 'checkbox',
			)
		);
	}

As you change the number of controls generated, the refresh takes longer and longer and longer.

This problem affects ALL themes using the customizer. For themes with maybe 50 or fewer options, the issues is tolerable, although there is a noticible delay. For themes with more, the delay for the user gets to be a real problem. And for themes like mine (Weaver Xtreme 2.0, work in progress, but stuck with this issue), that does in fact have 600 or more options, this is a FATAL issue.

There is no reason that dealing with a mere number of options on the order of 100's should crash the Customizer.

Somebody needs to open their algorithm book and find faster way to do the multidimensional_replace.

[westonruter]

@wpweaver: Thanks for the report, but this is a known issue. Please see #32103, and especially try the patch which is currently pending commit. If you could test it and verify that it resolves the issue, please give a +1 on the ticket. Thank you.