Thanks for the report. We were able to reproduce this (also in https://forum.matomo.org/t/problems-while-upgrading-to-3-9-0/32112 ) and after a refresh (go to Matomo root) it works. Have you tried going to your Matomo (without any path) and does it work?

Yes, apart from the warning described in #14226 the installation seems to work fine.

Same issue here. Is the matomo installation now broken? I run manually core:update and there are no changes in the database.

@poldixd No, the installation should work fine after a page reload.

@poldixd No, the installation should work fine after a page reload.

But I got some errors when I run the core:archive

INFO [2019-03-19 10:43:46] 8038  Will pre-process for website id = 51, period = day, date = last52
INFO [2019-03-19 10:43:46] 8038  - pre-processing all visits
WARNING [2019-03-19 10:43:47] 8038  /var/www/vhosts/PIWIK_INSTALLATION/httpdocs/core/Common.php(271): Notice - unserialize(): Error at offset 0 of 2136 bytes - Matomo 3.9.0 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already)
ERROR [2019-03-19 10:43:47] 8038  Empty or invalid response '[2019-03-19 10:43:46] piwik.DEBUG: Loaded plugins: CorePluginsAdmin, CoreAdminHome, CoreHome, WebsiteMeasurable, IntranetMeasurable, Diagnostics, CoreVisualizations, Proxy, API, Widgetize, Transitions, LanguagesManager, Actions, Dashboard, MultiSites, Referrers, UserLanguage, DevicesDetection, Goals, Ecommerce, SEO, Events, UserCountry, VisitsSummary, VisitFrequency, VisitTime, VisitorInterest, ExampleAPI, RssWidget, Monolog, Login, TwoFactorAuth, UsersManager, SitesManager, Installation, CoreUpdater, CoreConsole, ScheduledReports, UserCountryMap, Live, CustomVariables, PrivacyManager, ImageGraph, Annotations, MobileMessaging, Overlay, SegmentEditor, Morpheus, Contents, BulkTracking, Resolution, DevicePlugins, Heartbeat, Intl, Marketplace, ProfessionalServices, UserId, CustomPiwikJs, DBStats, Provider, TagManager [] {"class":"Piwik\\Plugin\\Manager","request_id":9317} a:52:{s:10:"2019-01-27";a:0:{}s:10:"2019-01-28";a:0:{}s:10:"2019-01-29";a:0:{}s:10:"2019-01-30";a:0:{}s:10:"2019-01-31";a:0:{}s:10:"2019-02-01";a:0:{}s:10:"2019-02-02";a:0:{}s:10:"2019-02-03";a:0:{}s:10:"2019-02-04";a:0:{}s:10:"2019-02-05";a:0:{}s:10:"2019-02-06";a:0:{}s:10:"2019-02-07";a:0:{}s:10:"2019-02-08";a:0:{}s:10:"2019-02-09";a:0:{}s:10:"2019-02-10";a:0:{}s:10:"2019-02-11";a:0:{}s:10:"2019-02-12";a:0:{}s:10:"2019-02-13";a:0:{}s:10:"2019-02-14";a:0:{}s:10:"2019-02-15";a:0:{}s:10:"2019-02-16";a:0:{}s:10:"2019-02-17";a:0:{}s:10:"2019-02-18";a:0:{}s:10:"2019-02-19";a:0:{}s:10:"2019-02-20";a:0:{}s:10:"2019-02-21";a:0:{}s:10:"2019-02-22";a:0:{}s:10:"2019-02-23";a:0:{}s:10:"2019-02-24";a:0:{}s:10:"2019-02-25";a:0:{}s:10:"2019-02-26";a:0:{}s:10:"2019-02-27";a:0:{}s:10:"2019-02-28";a:0:{}s:10:"2019-03-01";a:0:{}s:10:"2019-03-02";a:0:{}s:10:"2019-03-03";a:0:{}s:10:"2019-03-04";a:0:{}s:10:"2019-03-05";a:0:{}s:10:"2019-03-06";a:0:{}s:10:"2019-03-07";a:0:{}s:10:"2019-03-08";a:0:{}s:10:"2019-03-09";a:0:{}s:10:"2019-03-10";a:0:{}s:10:"2019-03-11";a:0:{}s:10:"2019-03-12";a:0:{}s:10:"2019-03-13";a:0:{}s:10:"2019-03-14";a:0:{}s:10:"2019-03-15";a:0:{}s:10:"2019-03-16";a:0:{}s:10:"2019-03-17";a:0:{}s:10:"2019-03-18";a:0:{}s:10:"2019-03-19";a:0:{}}' for website id 51, Time elapsed: 0.611s, skipping

That's an unrelated problem discussed there #14229

Same happened to me, was about to post this as new issue, but see it is already open.

This happened to me today on 2 different servers (one VPS self-managed running 3.8.9, another shared cPanel hosting running 3.7.0).

On one-click update page I received this message in Browser (not error log):

Matomo encountered an error: Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() (which lead to: Circular dependency detected while trying to resolve entry 'Piwik\Twig')

This is not a coincidence or a temporary glitch.

However, from that point things were different:

[1] on VPS version 3.8.9 in which I manually fixed database (there was something posted here what we should do, check some missing table or something like that), simple hitting back in browser produced another error notice (this was in log):

Error in Matomo: Your Matomo version 3.9.0 is up to date.

And that was it. Refreshing the page and all returned back everything to normal.

[2] On shared hosting version 3.7.0 I entered into the login page (again) and database required upgrade page, and then it was completed. I guess this part was normal, since some more things changed in between 370/390.

Interesting enough, there was nothing about that Twig thing in php error log.

Also just happened to me, on two different servers, Matomo seems to work fine.

But it's never great to be greeted with an error like Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() ... Like @koda writes:

After the last couple upgrades I was hesitant to use the automatic upgrade option, but like many people I am sure, we’re anxious for the latest code, so I took a risk, and once again, a serious error immediately appeared

Matomo encountered an error: Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() (which lead to: Circular dependency detected while trying to resolve entry ‘Piwik\Twig’)

Seeing new versions is bitter sweet, you get excited to see new options, bug fixes, but it’s nerve wrecking not knowing if you’re going to loose critical data by simply upgrading

From 3.9.0 Upgrade Errors

👋 Same as above "Error after upgrading via browser"
Matomo encountered an error: Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() (which lead to: Circular dependency detected while trying to resolve entry 'Piwik\Twig')

PHP: 7.1.27

Surely there will be version 3.9.1 🎉 😉

I got the same error after updating, using PHP 7.2.15. Reload root page works so far, but I got warnings on all pages.

WARNING: /var/www/piwik/htdocs/core/Plugin/Manager.php(451): Warning - is_dir(): open_basedir restriction in effect. File(/var/www/piwik/htdocsplugins/Insights) is not within the allowed path(s): (/var/www/piwik/htdocs/:/var/www/piwik/apps/:/var/www/piwik/priv/:/var/www/piwik/tmp/:/usr/share/pear/:/usr/share/php/:/tmp/) - Matomo 3.9.0

As you can see, there is a "/" missing bewteen "htdocs" and "plugins"
I changed line 450 to
$corePluginsDir = PIWIK_INCLUDE_PATH . '/plugins/' . $pluginName;
and the error messages are gone.

Updated from 3.8 to 3.9
Matomo encountered an error: Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() (which lead to: Circular dependency detected while trying to resolve entry 'Piwik\Twig')

After reload index.php no error, looks like everything is fine. Another misstype piwik vs matomo ?

php 5.6.40

I've got the same issue on three different servers. On all of them I hit refresh and clicked on "Back to Matomo". Then all seems fine. But I am still curious if the update was done successfully because it was very fast for that installation size.

I answered too early. I now get bombarded with errors of my Matomo cronjobs.

It looks like this:

WARNING [2019-03-20 11:11:25] 29344  /home/piwik/htdocs/piwik/core/Common.php(271): Notice - unserialize(): Error at offset 0 of 107327 bytes - Matomo 3.9.0 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already)
ERROR [2019-03-20 11:11:25] 29344  Empty or invalid response '[2019-03-20 11:11:24] piwik.DEBUG: Loaded plugins: CorePluginsAdmin, CoreAdminHome, CoreHome, WebsiteMeasurable, IntranetMeasurable, Diagnostics, CoreVisualizations, Proxy, API, Widgetize, Transitions, LanguagesManager, Actions, Dashboard, MultiSites, Referrers, UserLanguage, DevicesDetection, Goals, Ecommerce, SEO, Events, UserCountry, VisitsSummary, VisitFrequency, VisitTime, VisitorInterest, ExampleAPI, RssWidget, Feedback, Monolog, Login, TwoFactorAuth, UsersManager, SitesManager, Installation, CoreUpdater, CoreConsole, ScheduledReports, UserCountryMap, Live, CustomVariables, PrivacyManager, ImageGraph, Annotations, MobileMessaging, Overlay, SegmentEditor, Insights, Morpheus, Contents, BulkTracking, Resolution, DevicePlugins, Heartbeat, Intl, Marketplace, ProfessionalServices, UserId, CustomPiwikJs, CustomOptOut [] {"class":"Piwik\\Plugin\\Manager","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     count(distinct log_visit.idvisitor) AS `1`,     count(*) AS `2`,     sum(log_visit.visit_total_actions) AS `3`,     max(log_visit.visit_total_actions) AS `4`,     sum(log_visit.visit_total_time) AS `5`,     sum(case log_visit.visit_total_actions when 1 then 1 when 0 then 1 else 0 end) AS `6`,     sum(case log_visit.visit_goal_converted when 1 then 1 else 0 end) AS `7`,     count(distinct log_visit.user_id) AS `39`    FROM     piwik_log_visit AS log_visit    WHERE     log_visit.visit_last_action_time >= ?     AND log_visit.visit_last_action_time <= ?     AND log_visit.idsite IN (?) [] {"class":"VisitsSummary","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: PluginsArchiver::callAggregateAllPlugins: Initializing archiving process for all plugins [visits = 2, visits converted = 0] ["callAggregateAllPlugins",2,"0"] {"class":"VisitsSummary","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: PluginsArchiver::callAggregateAllPlugins: Archiving day reports for plugin 'Actions'. ["callAggregateAllPlugins","Actions"] {"class":"VisitsSummary","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     log_action.name,                 log_action.type,                 log_action.idaction,                 log_action.url_prefix, count(distinct log_link_visit_action.idvisit) as `2`, count(distinct log_link_visit_action.idvisitor) as `1`, count(*) as `12`, sum(                         case when custom_float is null                             then 0                             else custom_float                         end                 ) / 1000 as `30`, sum(                     case when custom_float is null                         then 0                         else 1                     end                 ) as `31`, min(custom_float) / 1000 as `32`, max(custom_float) / 1000 as `33`,                 CASE WHEN (MAX(log_link_visit_action.custom_var_v5) = 0                     AND log_link_visit_action.custom_var_k5 = '_pk_scount')                 THEN 1 ELSE 0 END                     AS `28`,                 SUM( CASE WHEN log_action_name_ref.type = 8                       THEN 1 ELSE 0 END)                     AS `29`    FROM     piwik_log_link_visit_action AS log_link_visit_action LEFT JOIN piwik_log_action AS log_action ON log_link_visit_action.%s = log_action.idaction LEFT JOIN piwik_log_action AS log_action_name_ref ON log_link_visit_action.idaction_name_ref = log_action_name_ref.idaction    WHERE     log_link_visit_action.server_time >= ?     AND log_link_visit_action.server_time <= ?     AND log_link_visit_action.idsite IN (?) AND log_link_visit_action.%s IS NOT NULL AND log_link_visit_action.idaction_event_category IS NULL    GROUP BY     log_link_visit_action.%s    ORDER BY     `12` DESC, name ASC [] {"class":"Actions","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     log_action.name,                 log_action.type,                 log_action.idaction,                 log_action.url_prefix, count(distinct log_link_visit_action.idvisit) as `2`, count(distinct log_link_visit_action.idvisitor) as `1`, count(*) as `12`, sum(                         case when custom_float is null                             then 0                             else custom_float                         end                 ) / 1000 as `30`, sum(                     case when custom_float is null                         then 0                         else 1                     end                 ) as `31`, min(custom_float) / 1000 as `32`, max(custom_float) / 1000 as `33`,                 CASE WHEN (MAX(log_link_visit_action.custom_var_v5) = 0                     AND log_link_visit_action.custom_var_k5 = '_pk_scount')                 THEN 1 ELSE 0 END                     AS `28`,                 SUM( CASE WHEN log_action_name_ref.type = 8                       THEN 1 ELSE 0 END)                     AS `29`    FROM     piwik_log_link_visit_action AS log_link_visit_action LEFT JOIN piwik_log_action AS log_action ON log_link_visit_action.%s = log_action.idaction LEFT JOIN piwik_log_action AS log_action_name_ref ON log_link_visit_action.idaction_name_ref = log_action_name_ref.idaction    WHERE     log_link_visit_action.server_time >= ?     AND log_link_visit_action.server_time <= ?     AND log_link_visit_action.idsite IN (?) AND log_link_visit_action.%s IS NOT NULL AND log_link_visit_action.idaction_event_category IS NULL    GROUP BY     log_link_visit_action.%s    ORDER BY     `12` DESC, name ASC [] {"class":"Actions","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     log_visit.visit_entry_idaction_url as idaction, log_action.type, log_action.name,                 count(distinct log_visit.idvisitor) as `17`,                 count(*) as `19`,                 sum(log_visit.visit_total_actions) as `20`,                 sum(log_visit.visit_total_time) as `21`,                 sum(case log_visit.visit_total_actions

I answered too early. I now get bombarded with errors of my Matomo cronjobs.

It looks like this:

WARNING [2019-03-20 11:11:25] 29344  /home/piwik/htdocs/piwik/core/Common.php(271): Notice - unserialize(): Error at offset 0 of 107327 bytes - Matomo 3.9.0 - Please report this message in the Matomo forums: https://forum.matomo.org (please do a search first as it might have been reported already)
ERROR [2019-03-20 11:11:25] 29344  Empty or invalid response '[2019-03-20 11:11:24] piwik.DEBUG: Loaded plugins: CorePluginsAdmin, CoreAdminHome, CoreHome, WebsiteMeasurable, IntranetMeasurable, Diagnostics, CoreVisualizations, Proxy, API, Widgetize, Transitions, LanguagesManager, Actions, Dashboard, MultiSites, Referrers, UserLanguage, DevicesDetection, Goals, Ecommerce, SEO, Events, UserCountry, VisitsSummary, VisitFrequency, VisitTime, VisitorInterest, ExampleAPI, RssWidget, Feedback, Monolog, Login, TwoFactorAuth, UsersManager, SitesManager, Installation, CoreUpdater, CoreConsole, ScheduledReports, UserCountryMap, Live, CustomVariables, PrivacyManager, ImageGraph, Annotations, MobileMessaging, Overlay, SegmentEditor, Insights, Morpheus, Contents, BulkTracking, Resolution, DevicePlugins, Heartbeat, Intl, Marketplace, ProfessionalServices, UserId, CustomPiwikJs, CustomOptOut [] {"class":"Piwik\\Plugin\\Manager","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     count(distinct log_visit.idvisitor) AS `1`,     count(*) AS `2`,     sum(log_visit.visit_total_actions) AS `3`,     max(log_visit.visit_total_actions) AS `4`,     sum(log_visit.visit_total_time) AS `5`,     sum(case log_visit.visit_total_actions when 1 then 1 when 0 then 1 else 0 end) AS `6`,     sum(case log_visit.visit_goal_converted when 1 then 1 else 0 end) AS `7`,     count(distinct log_visit.user_id) AS `39`    FROM     piwik_log_visit AS log_visit    WHERE     log_visit.visit_last_action_time >= ?     AND log_visit.visit_last_action_time <= ?     AND log_visit.idsite IN (?) [] {"class":"VisitsSummary","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: PluginsArchiver::callAggregateAllPlugins: Initializing archiving process for all plugins [visits = 2, visits converted = 0] ["callAggregateAllPlugins",2,"0"] {"class":"VisitsSummary","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: PluginsArchiver::callAggregateAllPlugins: Archiving day reports for plugin 'Actions'. ["callAggregateAllPlugins","Actions"] {"class":"VisitsSummary","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     log_action.name,                 log_action.type,                 log_action.idaction,                 log_action.url_prefix, count(distinct log_link_visit_action.idvisit) as `2`, count(distinct log_link_visit_action.idvisitor) as `1`, count(*) as `12`, sum(                         case when custom_float is null                             then 0                             else custom_float                         end                 ) / 1000 as `30`, sum(                     case when custom_float is null                         then 0                         else 1                     end                 ) as `31`, min(custom_float) / 1000 as `32`, max(custom_float) / 1000 as `33`,                 CASE WHEN (MAX(log_link_visit_action.custom_var_v5) = 0                     AND log_link_visit_action.custom_var_k5 = '_pk_scount')                 THEN 1 ELSE 0 END                     AS `28`,                 SUM( CASE WHEN log_action_name_ref.type = 8                       THEN 1 ELSE 0 END)                     AS `29`    FROM     piwik_log_link_visit_action AS log_link_visit_action LEFT JOIN piwik_log_action AS log_action ON log_link_visit_action.%s = log_action.idaction LEFT JOIN piwik_log_action AS log_action_name_ref ON log_link_visit_action.idaction_name_ref = log_action_name_ref.idaction    WHERE     log_link_visit_action.server_time >= ?     AND log_link_visit_action.server_time <= ?     AND log_link_visit_action.idsite IN (?) AND log_link_visit_action.%s IS NOT NULL AND log_link_visit_action.idaction_event_category IS NULL    GROUP BY     log_link_visit_action.%s    ORDER BY     `12` DESC, name ASC [] {"class":"Actions","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     log_action.name,                 log_action.type,                 log_action.idaction,                 log_action.url_prefix, count(distinct log_link_visit_action.idvisit) as `2`, count(distinct log_link_visit_action.idvisitor) as `1`, count(*) as `12`, sum(                         case when custom_float is null                             then 0                             else custom_float                         end                 ) / 1000 as `30`, sum(                     case when custom_float is null                         then 0                         else 1                     end                 ) as `31`, min(custom_float) / 1000 as `32`, max(custom_float) / 1000 as `33`,                 CASE WHEN (MAX(log_link_visit_action.custom_var_v5) = 0                     AND log_link_visit_action.custom_var_k5 = '_pk_scount')                 THEN 1 ELSE 0 END                     AS `28`,                 SUM( CASE WHEN log_action_name_ref.type = 8                       THEN 1 ELSE 0 END)                     AS `29`    FROM     piwik_log_link_visit_action AS log_link_visit_action LEFT JOIN piwik_log_action AS log_action ON log_link_visit_action.%s = log_action.idaction LEFT JOIN piwik_log_action AS log_action_name_ref ON log_link_visit_action.idaction_name_ref = log_action_name_ref.idaction    WHERE     log_link_visit_action.server_time >= ?     AND log_link_visit_action.server_time <= ?     AND log_link_visit_action.idsite IN (?) AND log_link_visit_action.%s IS NOT NULL AND log_link_visit_action.idaction_event_category IS NULL    GROUP BY     log_link_visit_action.%s    ORDER BY     `12` DESC, name ASC [] {"class":"Actions","request_id":29718} [2019-03-20 11:11:24] piwik.DEBUG: /* trigger = CronArchive */     SELECT     log_visit.visit_entry_idaction_url as idaction, log_action.type, log_action.name,                 count(distinct log_visit.idvisitor) as `17`,                 count(*) as `19`,                 sum(log_visit.visit_total_actions) as `20`,                 sum(log_visit.visit_total_time) as `21`,                 sum(case log_visit.visit_total_actions

same problem here

@NicolasGoeddel Please apply this patch and report back if it solved the problem: https://patch-diff.githubusercontent.com/raw/matomo-org/matomo/pull/14239.patch

@NicolasGoeddel Please apply this patch and report back if it solved the problem: https://patch-diff.githubusercontent.com/raw/matomo-org/matomo/pull/14239.patch

It solved the cronjob issue. It runs fine now. I will now check the smaller servers.

My error log is empty, nothing interesting besides above error message that it is already up to date / version 3.9.0 .

The smaller servers with only one site on it did not show any issues but I patched them anyway.

That patch will go live soon(tm) with version 3.9.1.

Got the same warnings after update to 3.9.0 like @pitgrap and change this file, too.
Warning Messages are gone after that.

Now I understand the meaning of ❗ in update notifications 😃

(you're gonna hate me for this joke, I know...)

This is still happening to me on several installations during update from 3.7.0 or 3.8.9 to 3.9.1 - is this normal/expected?

Matomo encountered an error: Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() (which lead to: Circular dependency detected while trying to resolve entry ‘Piwik\Twig’)

Also, this happened in one setup (3.8.9 -> 3.9.1) when I hit back in browser:

Mysqli statement execute error : Prepared statement needs to be re-prepared
The Matomo configuration file couldn't be found and you are trying to access a Matomo page.
» You may install Matomo now
If you installed Matomo before and have some tables in your DB, don't worry, you can reuse the same tables and keep your existing data!

Then I edited URL to visit home matomo page and this was shown:

Error: Matomo is already installed.
Original error was "Mysqli statement execute error : Prepared statement needs to be re-prepared".
Go back to Matomo.

Then I hit refresh in browser and was presented with database update required page.
Then, I had to re-login again.

From there, everything seems to be fine.
Not sure what happened here, really.

Ok, my PHP error log is filled with these lines (after the update no new error log entries were found - will keep monitoring it next couple of days):

[20-Mar-2019 18:12:34 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[20-Mar-2019 19:28:34 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[20-Mar-2019 21:04:31 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[20-Mar-2019 22:28:46 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 00:25:32 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 06:29:08 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 07:14:48 UTC] PHP Warning:  "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /matomo/vendor/tedivm/jshrink/src/JShrink/Minifier.php on line 243

[21-Mar-2019 08:50:03 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 10:27:57 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 11:38:41 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 12:40:14 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 13:59:49 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 14:34:34 UTC] PHP Warning:  "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /matomo/vendor/tedivm/jshrink/src/JShrink/Minifier.php on line 243

@dev-101 Does the file /matomo/vendor/tedivm/jshrink/src/JShrink/Minifier.php still exist after updating to 3.9.x ? That file should actually be removed in 3.9.0, as we changed the composer dependency. It should then be located at /matomo/vendor/matomo-org/jshrink/src/JShrink/Minifier.php

I can confirm that it is now in new location (old location was removed during update, probably).
So far, after update, I do not see anything strange and no further errors.
I assume this was a one-time update issue, hopefully it will not happen next time.

Thanks!

This is still happening to me on several installations during update from 3.7.0 or 3.8.9 to 3.9.1 - is this normal/expected?

Unfortunately, yes. The bug is in the old code and occurs right before the update finishes, when the old code is still in memory. Which means the update process can't get rid of the bug in time (so-to-speak). It won't happen when upgrading from 3.9.1, but I don't think there's a way to get rid of it on upgrading from before then since the bug is in the one click update process itself. @mattab we may want to patch old releases if we want to avoid users seeing this error.

Ok, there is one new error entry (forgot to check before replying to sgiehl above, my initial checks were fine an hour ago):

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

Not sure why that one happen, need to monitor and determine what actually triggers it.

Update: Well, just cleared the log and tried accessing main matomo page couple of times, no errors.
Probably another leftover, as on this shared hosting there might be a small delay before the entries in the logs are written (I don't have control over that part).

@diosmosis
Thank you for additional explanation. I hope so 👍

Unfortunately, this is not a glitch, it is still happening and here are the timestamps from the log:

[21-Mar-2019 16:50:43 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 18:48:45 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

[21-Mar-2019 19:57:35 UTC] PHP Warning:  session_cache_limiter(): Cannot change cache limiter when headers already sent in /matomo/core/bootstrap.php on line 32

Roughly, it occurs once per hour and it seems that this is either triggered by some cron internal process, or some visitor session (it is not triggered by myself visiting dashboard for sure).

Update: just checked my other shared-hosting installations logs, same happens there, too - at irregular intervals e.g. once in 1-4 hours, which suggests something from above (e.g. cron and/or relation to number of visits). Interestingly enough, this doesn't happen on VPS servers, logs are silent about this (occasionally get unable to start session message for some visits, but's that is another Matomo's unrelated issue).

I just updated from 3.9.0 to 3.9.1, and it went fine, without any errors.

I just updated from 3.8.1 to 3.9.1 and the first thing that happens:

Matomo encountered an error: Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() (which lead to: Circular dependency detected while trying to resolve entry 'Piwik\Twig')

After reloading I can go back to the dashboard. Anyways, the issue is not resolved yet, I'm afraid.

Edit: It happened again with my second Matomo instance I just updated

Same here, while updating from 3.8.1 to 3.9.1 with automatic update
https://piwik.xxxx.be/index.php?module=CoreUpdater&action=oneClickUpdate this is displayed
Matomo encountered an error: Call to undefined method Piwik\Plugin\Manager::getPluginDirectory() (which lead to: Circular dependency detected while trying to resolve entry 'Piwik\Twig')

@kghbln @Polfo see my comment: #14227 (comment)

@diosmosis Thanks for the pointer and the insight. This bug was advertised as fixed which is obviously not always the case. This is confusing if users do not get a note about this information. Or (fails only once, works after a refresh) was the note which I misinterpreted. ;)

Anyone else getting PHP Warning: session_cache_limiter() warnings in php error logs after update to 3.9.1 ? Can't be it's just me :)

According to php manual:

The cache limiter is reset to the default value stored in session.cache_limiter at request startup time. Thus, you need to call session_cache_limiter() for every request (and before session_start() is called).

Hope this is already the case.

Anyone else getting PHP Warning: session_cache_limiter() warnings in php error logs after update to 3.9.1 ?

No.

@diosmosis Thanks for the pointer and the insight. This bug was advertised as fixed which is obviously not always the case. This is confusing if users do not get a note about this information. Or (fails only once, works after a refresh) was the note which I misinterpreted. ;)

@kghbln Yes, we should probably mention this to users somehow, otherwise there will probably be many more reports like this cc @mattab