Rogier Lankhorst

Hi @tobaco,

Thanks for reporting the issue. The testing only occurs every 10 minutes if the last test fails: if the test succeeds, the interval is 24 hours.

To prevent this from happening every 10 minutes, I’ve added a filter here:
https://github.com/Burst-Statistics/burst/tree/add-time-between-endpoint-test-filter

You can install it using the green button, and download the zip file. The deactivate your current Burst plugin, and install this one like a normal plugin.

If you add the following snippet as a mu-plugin you can override the test interval:

/**
 * Override the default time between tests, which is 10 minutes when the last test returned an error, and 24 hours otherwise.
 * 
 * @param int $time_between_tests //the time between tests in seconds
 * @return int
 */
function burst_time_between_tests(int $time_between_tests ): int
{
    return WEEK_IN_SECONDS;
}
add_filter( 'burst_time_between_tests', 'burst_time_between_tests' );

This will be merged in one of the upcoming releases, it will be mentioned in the changelog.

Let me know if this helps!

@mplanet5 are there any other errors you can see in the console? Can you post the entire error here, including the character and line number?

Are you updated to the latest version of Burst? And is the entire page blank, or just a part?

If you install the WP Debugging plugin, do you get any PHP errors in the debug log?

Any information might help. As I can’t reproduce it myself, I have to deduce the issue purely based on your info.

@tobaco this is the filter for all REST url’s, so Burst should pass through it as well. Could this be caused by caching?

Not sure why other plugins don’t have this issue, but it could be they already have a fix in place, or they don’t use the wp.apiFetch method? The REST route is declared with standard WordPress code.

@jmacofearth thanks for your suggestion, we’ll add it to the wishlist, and discuss it internally.

Can you try to add the following snippet to your site as an mu-plugin?

It will strip the language from the Burst rest api.

/**
 * Fix for WPML issue where WPML breaks the rest api by adding a language locale in the url
 *
 * @param $url
 * @param $path
 * @param $blog_id
 * @param $scheme
 *
 * @return string
 */
function burst_my_fix_rest_url_for_wpml($url, $path, $blog_id, $scheme)
{
	if (strpos($url, 'burst/v') === false) {
		return $url;
	}

	$current_language = false;
	if (function_exists('icl_register_string')) {
		$current_language = apply_filters('wpml_current_language', null);
	}

	if ($current_language) {
		if (strpos($url, '/'.$current_language.'/wp-json/')) {
			$url = str_replace('/'.$current_language.'/wp-json/', '/wp-json/', $url);
		}
	}

	return $url;
}

add_filter('rest_url', 'burst_my_fix_rest_url_for_wpml', 10, 4);

are there any console errors visible in the browser when the blank screen happens? The user can check this in Chrome by right clicking on the screen, then click “inspect element”, “console”.

The language plugin probably inserts the language in the rest_api url. What plugin are you using?

The default configuration is tracking with an endpoint instead of the rest api. The endpoint is located in wp-content/plugins/burst-statistics/endpoint.php

If the rest api is used, this means the endpoint is probably blocked by either a security plugin or your hosting provider.

If this block can be removed, the site can use the endpoint again, which could be a work around for the language insertion in the URL.

@ythhj it sounds like a caching problem in the browser. Can she try logging in with a different browser, or in a private window?

If that helps, clearing the browser cache should also resolve the issue.

If you deactivate the plugin, then activate again, the creation of capabilities runs again. This might fix any capability differences between your administrator. Let me know if that helps!

@conny64 could also be a caching issue in that case (where the site kept serving old .js files for a while which didn’t match with the new server side code).

@ncwebmaster the statistics consent configuration can be found in Complianz -> Wizard -> Consent. Then you have two menu items: statistics, and (conditionally) statistics configuration. Here you have options which decide how consent on statistics is handled. If you have selected “ask consent for statistics”, no hits are tracked until consent is given, unless you have enabled cookieless tracking in Burst.

• This reply was modified 2 months ago by Rogier Lankhorst.

Thanks for the detailed report, and great it works now!

@macmandk I will look into that, but as it’s technically very different, please open a new support topic. Otherwise things can get confused here.

@ncwebmaster and @conny64 there have been changes in the integration, which might change how it works if you have originally configured Complianz to block statistics until consent is given.

Please check if you have originally set Complianz to ask for consent for statistics. If so, this is probably the cause. If not, I’ll investigate further.

The easiest method to install is to open your WordPress dashboard, then go to plugins, click “add new”, then type in “wp consent api”.

The plugin should then show up in the results, and you can install it from the dashboard. Hope this helps.

@conny64 @ncwebmaster do you have configured Complianz to ask consent for statistics?

@shayshay18 are there any php errors in the debug.log? You can check by installing the wp debugging plugin.