Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
New event that allows plugins to archive 3rd party data #8631
Currently, it is not possible to store 3rd party reports in archive tables (at least w/o some large hacks) due to this one optimization: https://github.com/piwik/piwik/blob/master/core/ArchiveProcessor/Loader.php#L121
If there are no visits for a period, the Archiver code for a plugin will not be launched. For plugins that only provide 3rd party data, there will never be visits in the log_visit table, so the archiver will never be launched.
To fix this for our LTS version, we can add an event that specifies idSites for whom this optimization should be skipped. This will allow many more plugins to be created for 2.15, while we work on 3.0.
Potential names for the new event include:
referenced this issue
Aug 24, 2015
I thought quite for a while for a good name that actually describes what we're looking for but couldn't find any. For example one could display third party data but still reuse
The ideal solution would be to either to refactor the archiver (which is planned for 3.0) and/or to offer a kinda new API for them, which could be even just a different method in the archiver for simplicity. For example next to
I'm not sure how much work it is to introduce such new API but imagine it rather trivial, not sure though. When we detect a plugin defining an importer one would also maybe not have to listen to the
This issue is just for enabling developers to display 3rd party data w/ as small a change as possible. 3.0 won't be out for 8 months or so, and I don't think plugin developers (ie, pro devs & their clients) should have to wait for that time to use this functionality. A new 'component' class might be the proper solution, but it doesn't make sense to write all that code when it may be removed for 3.0 and when a single pre-deprecated event will solve it too.
Regarding the name, since it will be removed eventually, I don't really have a preference. If you prefer technically accurate naming, maybe
I'm fine with any event name as long as it doesn't contain
I'm fine with using the event as a workaround and to develop maybe a new base class in Piwik 3.0 for importing data.