matomo-org / matomo

Empowering People Ethically with the leading open source alternative to Google Analytics that gives you full control over your data. Matomo lets you easily collect data from websites & apps and visualise this data and extract insights. Privacy is built-in. Liberating Web Analytics. Star us on Github? +1. And we love Pull Requests!
https://matomo.org/
GNU General Public License v3.0
19.93k stars 2.66k forks source link

Warning when using Matomo + WordPress: "Warning: session_cache_limiter(): Cannot change cache limiter when session is active ..." #12963

Open ghost opened 6 years ago

ghost commented 6 years ago

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

https://wordpress.org/support/topic/session_cache_limiter-warnings-when-wp-piwik-is-enabled/#post-10311647

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

https://github.com/matomo-org/matomo/issues/885

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

I did try adding

    define('PIWIK_ENABLE_SESSION_START', true);

or

    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 6 years ago

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 6 years ago

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

Mannshoch commented 5 years ago

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 5 years ago

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 5 years ago

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

Sudrien commented 5 years ago

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)

tsteur commented 5 years ago

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 5 years ago

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.

tsteur commented 5 years ago

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 5 years ago

@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();
}
tsteur commented 5 years ago

@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 5 years ago

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

Findus23 commented 5 years ago

@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

tsteur commented 5 years ago

@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 5 years ago

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'); }

tsteur commented 5 years ago

Not sure which boostrap.php you refer to?

Sudrien commented 5 years ago

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

tsteur commented 5 years ago

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

tsteur commented 5 years ago

Updated the PR