@tsteur opened this Issue on October 27th 2014 Owner

To prevent random issues / to make core more stable.

Ideally, it should not matter in which order the plugins are loaded. I think we had at least one case where the plugin order caused an error though and something like this is really hard to debug. At least we can make sure the plugin order is not a problem if we load them always in the same order. Probably we had this case a few times but couldn't find the issue. If I remember correct it is already important that the themes are loaded in a specific order to make sure Morpheus overrides something from other plugins (forgot what it was).

We had for instance users that upgraded from an older version to a newer one and the order of the plugins was different. The order also may change when someone disables/enables a plugin.

Therefore, we should load all plugins in the same order as defined in global.ini.php. Plugins that are not defined in global.ini.php can be still loaded randomly as long as they are loaded after all core plugins.

@quba commented on October 27th 2014 Contributor

+1

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

@tsteur commented on October 30th 2014 Owner

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?

@tsteur commented on October 30th 2014 Owner

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

@mattab commented on October 31st 2014 Owner

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

@tsteur commented on October 31st 2014 Owner

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

@mattab commented on October 31st 2014 Owner

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)

@hpsam commented on November 27th 2014

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"

@mattab commented on December 10th 2014 Owner

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.

@mattab commented on December 15th 2014 Owner

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

This Issue was closed on December 15th 2014
Powered by GitHub Issue Mirror