@ghost opened this Issue on May 23rd 2018

I've installed

    Matomo v3.5.0

on Nginx v1.14.0

It's working as expected as a standalone instance.

I've also installed

    WordPress 4.9.6
    WP-Matomo (WP-Piwik) plugin, v1.0.19

It's connected & tracking at my site

    "WP-Piwik 1.0.19 is successfully connected to Piwik 3.5.0. You are running WordPress 4.9.6."

In my WP site's Admin UI, I see this warning on each page:

    Warning: session_cache_limiter(): Cannot change cache limiter when session is active in /srv/www/piwik/core/bootstrap.php on line 32

I asked about this is WP-Matomo support forum @

session_cache_limiter warnings when WP-PIWIK is enabled


where the response by plugin's dev @braekling included

    There is nothing WP-Matomo can do about this. Matomo itself and WordPress or other plugins should check if the session is started already before calling session_cache_limiter.

So, I'm checking here next.

Notice: Constant PIWIK_ENABLE_SESSION_START already defined in /srv/www/piwik/bootstrap.php on line 8

I did find this old issue by @robocoder

Should dispatcher always start/resume session? #885


which seems to be (?) related, but looks like it was fixed long ago.

I did try adding

    define('PIWIK_ENABLE_SESSION_START', true);


    define('PIWIK_ENABLE_SESSION_START', false);

to Matomo's piwik/bootstrap.php, but that doesn't change the behavior. I just get

    Notice: Constant PIWIK_ENABLE_SESSION_START already defined in /srv/www/piwik/bootstrap.php on line 8

    Warning: session_cache_limiter(): Cannot change cache limiter when session is active in /srv/www/piwik/core/bootstrap.php on line 32

What in Matomo core code or config needs to be changed to correct this session_cache_limiter issue when used with WP/WP-Matomo plugin?

Or is this not a Matomo issue either, and needs to be raised @ WP Core?

@robocoder commented on May 23rd 2018 Contributor

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).

@ghost commented on May 23rd 2018


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


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

@Mannshoch commented on April 11th 2019

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

@zerosonesfun commented on July 13th 2019

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?

@N3X15 commented on July 17th 2019

Getting this on PHP 7.3, as well.

root<a class='mention' href='https://github.com/dedi'>@dedi</a>:~# 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<a class='mention' href='https://github.com/dedi'>@dedi</a>:~# 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().

@Sudrien commented on September 15th 2019

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



if ( version_compare(phpversion(), '7.2.0', '>=') && session_status() !== PHP_SESSION_ACTIVE ) {

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

@tsteur commented on September 15th 2019 Member

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+?

@Sudrien commented on September 15th 2019

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 ) {

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.

@tsteur commented on September 16th 2019 Member

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"?

@braekling commented on September 16th 2019

@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' )) {
        //<a class='mention' href='https://github.com/header'>@header</a>('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);
@tsteur commented on September 17th 2019 Member

@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.

@tsteur commented on September 17th 2019 Member

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

@Findus23 commented on September 17th 2019 Member

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

@tsteur commented on September 17th 2019 Member

@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

@Sudrien commented on September 19th 2019

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 ) {

@tsteur commented on September 19th 2019 Member

Not sure which boostrap.php you refer to?

@Sudrien commented on September 19th 2019
@tsteur commented on September 19th 2019 Member

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

@tsteur commented on September 19th 2019 Member

Updated the PR

Powered by GitHub Issue Mirror