In the past months we sometimes had troubles with extending the Updater / Installer.
config.ini.phpand then updating Piwik. Problem is when there are not only database changes but also local changes (eg modifying
piwik.js). Local changes would always need to be executed while database changes only might need to be executed when recorded component version in database is lower. Maybe we can separate those two use cases in the installer with different methods or so.
As the platform grew we simply have more and more requirements to the updater but maybe also to the installer. With the knowledge we have today we could maybe improve the code of the updater and add some more features to make updates more flexible.
in https://github.com/piwik/piwik/issues/6966 a bug was reported that may be caused by the fact that during Upgrades some calls to
activatePlugin may fail for example, when config file not writable. When the
activatePlugin call fails in this way currently it is within a try/catch block -> it silently fails and doesn't report error to user.
Instead of silently ignoring the
activatePlugin, we should WARN and explain user he should activate plugin manually. Maybe we need a new system in Updater to register commands like Plugin activation and Plugin deletion. Ideally thse commands would be also written during the
dry-run so that the dry-run would indicate almost all modifications done during an update.
Another issue (which is rather a "New feature" and should probably be in a separate issue) is that the upgrader should handle better the case when a plugin installation or upgrade triggers a large schema change, which times out in the browser. In some cases when the upgrade times out (or is it maybe in all cases?!), Piwik thinks that the plugin was successfully installed/upgraded although the schema changes were not fully done. This creates serious bugs such as https://github.com/piwik/plugin-MarketingCampaignsReporting/issues/13#issuecomment-330292411
There is a workaround for this issue, which is to uninstall & re-install the plugin, and run the
./console core:update in the console so it does not time out.
Just added another point to the list it would be very helpful if we were sometimes able to run SQL queries for updates in advance before updating the codebase. We would then also want to set a specific update script as "recorded" so it won't be executed again later. This works when the SQL query does not affect the product when using still an older codebase. This is something for advanced users only and we wouldn't make this probably much visible or at all. But we have to have the ability to run certain updates in advance and mark a certain update file as recorded. Also without getting the message "you are running an outdated codebase version of matomo with a newer DB version"
What about instead of tying migrations to update versions, they are tied to a creation timestamp which serves as both ID & indication of order? Would have two benefits: one in that you could create a command to run/undo ('undo' in the future at least) any set of migrations by it's ID, and would mean if you created an Update, you don't have to also change the matomo version.
Yes had something like this in mind too. We might even want to think about not mixing DB migrations with PHP migrations (eg config file etc) but that's a different topic and might not always be possible.