+1

I've encountered such issue once with a custom plugin and it took more than a day to debug.

We previously referenced issue was actually caused by this problem. Shows this seem to happen quite often and I think it is easy to fix. Maybe we can work on it for this or next release?

I just wanted to quickly implement it but noticed it is not that easy. One would think to bring the plugins in same order whenever we write the config in Config::writeConfig but the Config class should not have such knowledge about "Plugins" and should not sort it there. It should be very stupid and only read/write get/set values.

Next thought was to modify the plugins manager and sort them there but then things might be a bit harder to understand as the plugins would be loaded in a different order than defined in config.ini.php and one would never know in which order they are really loaded.

So we'd probably something like an event, callback or whatsoever before writing the config

@tsteur I have an idea for solving this problem. we've discussed it few times before and this idea is to store the list of plugins in the database rather than the config file. Then once they're stored in DB it simplifies some other aspects of managing Piwik (enabling a plugin won't require to have write permission on config file). Also storing in DB maybe means it will make sense the pluginManager would sort the plugins in the "default expected order".

What do you think about storing plugins in db?

It would be still the same "problem" and moving to DB would not change anything re this issue I think. So moving to DB is rather a different topic.

Moving to DB is something I'd have to think about for a while or 10 times better to implement it and see if it is actually a good idea or not. Affects quite a few things I reckon and we would still have to cache it on the filesystem (for tracker cache etc).

what I understood was the problem with ordering the plugins was that it could be a different order between config.ini.php and the actual order in which they are loaded which would be confusing. So I thought by storing the plugins in the DB we remove this inconsistency because in the DB it is expected that plugins are in random order. It makes sense then to me to order plugins in PluginManager since they come in random order from DB.

Anyway the solution to simply order plugins in PluginManager sounds good to me (and we accept the fact that config.ini.php Plugins order may not be respected)

I have the same issue this WE going from 2.1.0 to 2.9.1.
Thanks Matt on piwik forum for giving me the solutions.

The best solutions is like Linux services or TYPO3 plugins: each one define a list of required plugins that must be load before it. With that configuration a plugin can extend a plugin without load order error.

The plugins order that doesn't work for me is:
Plugins[] = "API"
Plugins[] = "Widgetize"
Plugins[] = "Dashboard"
Plugins[] = "Referers"
Plugins[] = "UserSettings"
Plugins[] = "UserCountry"
Plugins[] = "VisitsSummary"
Plugins[] = "VisitFrequency"
Plugins[] = "VisitTime"
Plugins[] = "VisitorInterest"
Plugins[] = "Provider"
Plugins[] = "Login"
Plugins[] = "UsersManager"
Plugins[] = "SitesManager"
Plugins[] = "Installation"
Plugins[] = "LanguagesManager"
Plugins[] = "MultiSites"
Plugins[] = "UserCountryMap"
Plugins[] = "CustomVariables"
Plugins[] = "PrivacyManager"
Plugins[] = "CoreHome"
Plugins[] = "CoreUpdater"
Plugins[] = "CoreAdminHome"
Plugins[] = "CorePluginsAdmin"
Plugins[] = "Proxy"
Plugins[] = "Actions"
Plugins[] = "SegmentEditor"
Plugins[] = "CoreConsole"
Plugins[] = "CoreVisualizations"
Plugins[] = "Referrers"
Plugins[] = "ScheduledReports"
Plugins[] = "Events"
Plugins[] = "Morpheus"
Plugins[] = "ReferrersManager"
Plugins[] = "ZenMode"
Plugins[] = "LeftMenu"
Plugins[] = "DevicesDetection"
Plugins[] = "Contents"

Maybe the easiest solution is to load core plugins in the order that they are specified in the global.ini.php file, and then up to us to decide the order for any core plugins.

Then for other plugins that are not in default release, it shouldn't matter which order they load in, since they are all optional.

it should fix it for you @hpsam thanks for pasting your config list, I found it useful!

Still an issue today. Some plugin does a DB call before I have the chance to set the DB config from env variables.

@pgampe Afaik plugins should be loaded in alphabetical order. But core plugins should be loaded first nevertheless.

@pgampe would you be able to identify which plugin that might be, e.g. if you could temporarily enable query logs on the database server (if in local development) or similar? What debugging did you do so far to figure out it is a plugin? Is there an error message you can share?

I think it did work as intended, but it was very hard to debug and understand.

I actually had another issue with the TLS connection to the DB server which resulted in an error message that looked like the DB credentials where not passed properly. The problem is that the mysqlnd extension does not provide proper error messages in that case. After hours of debugging, I found out that matomo was all right after all.