Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow invalidating plugin archives only and archiving past data for plugins #15889

Merged
merged 154 commits into from Aug 4, 2020

Conversation

diosmosis
Copy link
Member

@diosmosis diosmosis commented Apr 30, 2020

Fixes #11974

This PR is based off of #15499 .

Changes made:

  • we allow invalidating plugin specific archives, this results in entries being added to archive_invalidations for the plugin archive. they will not be added if we invalidate a normal archive, even if as part of that invalidation some dependent plugin specific archives (like ones created by VisitorInterest/Goals) are invalidated.
  • in core:archive, if we see a plugin specific archive in the invalidations table, we archive it separately w/ the pluginOnly=1 query parameter.
  • in Rules.php if in core:archive and pluginOnly=1 is used, we force creating a plugin specific archive.
  • in Archive.php/Loader.php/etc. we don't just look for one type of archive (ie, plugin vs all), we look through every one and use the latest archive values. so if there is an all archive and a ExamplePlugin archive that is more recent, the archive data in ExamplePlugin will be used for ExamplePlugin data, but other plugin data will come from all.
  • plugins on activation can then invalidate archives for their own plugin to schedule archiving for data in the past, without initiating archiving for every other plugin at the same time.

Notes:

  • browser archiving is not supported. If a user does not use core:archive, the invalidations don't do anything unless the plugin specific archive existed before. I think this is ok since premium plugins need this feature and we don't expect them to be used w/o core:archive, correct?

Example PR can be found in funnels

@tsteur
Copy link
Member

tsteur commented Jul 30, 2020

@diosmosis some tests seem to be failing now again. Can you check them out and merge once they pass? 🎉

@diosmosis diosmosis force-pushed the 11974-plugin-specific-archiving branch 2 times, most recently from b2403f7 to 3f0bc99 Compare July 31, 2020 07:51
@diosmosis diosmosis force-pushed the 11974-plugin-specific-archiving branch from 3f0bc99 to 059358c Compare July 31, 2020 08:42
@diosmosis diosmosis force-pushed the 11974-plugin-specific-archiving branch from d68c9e1 to 11072c0 Compare August 1, 2020 07:33
@diosmosis diosmosis force-pushed the 11974-plugin-specific-archiving branch from e50622b to 87fa4ac Compare August 1, 2020 10:49
@diosmosis
Copy link
Member Author

@tsteur build is passing now

@diosmosis diosmosis merged commit f5e9420 into 4.x-dev Aug 4, 2020
@diosmosis diosmosis deleted the 11974-plugin-specific-archiving branch August 4, 2020 03:00
@mattab mattab added Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. c: Usability For issues that let users achieve a defined goal more effectively or efficiently. labels Sep 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Usability For issues that let users achieve a defined goal more effectively or efficiently. Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc. Needs Review PRs that need a code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow plugins to generate their reports using historical data (eg. Custom Reports)
3 participants