@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

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

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

Powered by GitHub Issue Mirror