It sounds like you have session.auto_start enabled in your php.ini config. IIRC that can slow down tracking, so you might want to disable it (that's typically the default).

@robocoder

hm. NOT explicitly set anywhere in my config -- at all.

That said, as you say it should be default, I added an EXPLICIT config to my php.ini

session.auto_start = 0
```
And that cures the error^ from above -- no longer see it.

But now, the plugin in WP reports a constant/unending "Loading ..." status in the Toolbar, at

https://example.com/wp-admin/?page=wp-piwik_stats

which, I guess, is back to being a Plugin issue ... ?

Have the same Error.

Warning: session_cache_limiter(): Cannot change cache limiter when headers already sent in .../piwik/core/bootstrap.php on line 32

WP: 5.1.1–de_DE
Plugin: WP_Piwik 1.0.21

It not appears on a second Webspace with:
WP: 5.0.3 ? (not sure because I do not know where to check version)
Plugin: WP_Piwik 1.0.19

Both are on the same shared Webspace with the same configuration (which I could not change) and same .htacces

I just noticed my error log full of this warning for months. I can confirm this is real. Maybe a combination of WordPress and shared hosting environments where you're limited to what you can do. Any way to fix this on Matomo's side?

Getting this on PHP 7.3, as well.

root@dedi:~# php-fpm7.3 --version
PHP 7.3.7-1+0~20190710.40+debian9~1.gbp032aec (fpm-fcgi) (built: Jul 10 2019 07:38:52)
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.7, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.7-1+0~20190710.40+debian9~1.gbp032aec, Copyright (c) 1999-2018, by Zend Technologies

root@dedi:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

You probably need to check if the session's initialized already before running session_start().

Ok, got this error when upgrading from php7.0-fpm to php7.3-fpm - 7.2 is where the session logic changed, per experience.

It was on the dashboard, where I should see my stats, and WP-Matomo is configured to "Self hosted (PHP API)" because yes, it's on the same box.

Shouldn't this mean that it's WordPress that is starting the session, not the PHP API? If so, there would be a question of WHY Matomo is trying to modify session behavior.

My assumption is that the default HTTP API would not have similar behavior, but that's timing out on my configuration, so I can't test. Welp.

As this looks like bootstrap.php is used in other contexts, would replacing

session_cache_limiter('nocache');

With

if ( version_compare(phpversion(), '7.2.0', '>=') && session_status() !== PHP_SESSION_ACTIVE ) {
session_cache_limiter('nocache');
}

Work as a general case? (It make my wp dashboard error-free)

When you install Matomo on the same box as WordPress, it doesn't mean that WordPress is starting any session since they are still separate applications unless you refer here to the actual WP Matomo plugin that is causing the issue?

In the code you mention why should nocache only be set for PHP 7.2+?

I said the logic made me error-free, not that it was correct. Sorry @tsteur , It was late. Should be somthing closer to this:

if ( version_compare(phpversion(), '7.2.0', '<') || session_status() !== PHP_SESSION_ACTIVE ) {
session_cache_limiter('nocache');
}

The reported behavior does not effect WP-Matomo's tracking calls (which would be separate php sessions, because they are seperate http(s) calls), only the backend statistics display (which I can find no provision to keep the Matomo-managed PHP session seperate from the WordPress-managed PHP session)

If WP-Matomo is calling the PHP API incorrectly, without enough session isolation, that would also make sense.

Sorry I'm not so much into it. Could you tell us how your WordPress / WP-Matomo / Matomo is set up? Like do you bootstrap Matomo somehow within WordPress? What tracking mode do you have configured in WordPress Matomo? Not sure what you mean by viewing the "backend statistics"?

@tsteur WP-Matomo offers two options to get data from Matomo (Tracking code & site ID but also stats which are shown in the WordPress backend): HTTP API and PHP API.

The HTTP (=REST) API typically works great, but the PHP API may cause conflicts (duplicate class names, sessions, ...), because it has to include several core Matomo PHP files into WordPress (the PHP client is still mentioned here, but the documentation behind the link describes the REST API only).

Setting Matomo constants: https://github.com/braekling/WP-Matomo/blob/master/classes/WP_Piwik.php#L782

public static function definePiwikConstants() {
	if (! defined ( 'PIWIK_INCLUDE_PATH' )) {
		//@header('Content-type: text/html');
		define ( 'PIWIK_INCLUDE_PATH', self::$settings->getGlobalOption ( 'piwik_path' ) );
		define ( 'PIWIK_USER_PATH', self::$settings->getGlobalOption ( 'piwik_path' ) );
		define ( 'PIWIK_ENABLE_DISPATCH', false );
		define ( 'PIWIK_ENABLE_ERROR_HANDLER', false );
		define ( 'PIWIK_ENABLE_SESSION_START', false );
	}
}

And here the API calls are done: https://github.com/braekling/WP-Matomo/blob/master/classes/WP_Piwik/Request/Php.php#L25

if (file_exists(PIWIK_INCLUDE_PATH . "/index.php"))
	require_once PIWIK_INCLUDE_PATH . "/index.php";
if (file_exists(PIWIK_INCLUDE_PATH . "/core/API/Request.php"))
	require_once PIWIK_INCLUDE_PATH . "/core/API/Request.php";
if (class_exists('\Piwik\Application\Environment') && !self::$piwikEnvironment) {
	// Piwik 2.14.* compatibility fix
	self::$piwikEnvironment = new \Piwik\Application\Environment(null);
	self::$piwikEnvironment->init();
}

@braekling @Sudrien I'd be quite curious to look into this more. AFAIK wordpress does not have any session logic themselves and is basically not using session_start if I see this correctly? Is it maybe more a problem with specific other plugins that may use sessions? Just wondering how to best reproduce it and understanding the problem.

Or maybe it's more a general problem with that server setup and it is not related to wordpress at all basically?

@Sudrien
Someone on the forum had the same issue and reported back that they were using a Wordpress security plugin that was modifying how PHP works and therefore broke Matomo
https://forum.matomo.org/t/an-error-occurred/32500/3?u=lukas

@Sudrien @zerosonesfun could you maybe try this patch? Not sure if it helps but in that case if another plugin starts a session already, we would not start another one https://github.com/matomo-org/matomo/pull/14896/files

It's running, but it doesn't fix the original error.

...which yeah, the test in bootstrap.php could be shortened to

if ( session_status() !== PHP_SESSION_ACTIVE ) {
session_cache_limiter('nocache');
}

Not sure which boostrap.php you refer to?

https://github.com/matomo-org/matomo/blob/3.x-dev/core/bootstrap.php#L32 (presumably)

Thanks! I will update the patch. Didn't realise it was there as well.

Updated the PR