Have you tested whether they will be still archived later eg when archiving everything via CLI and later requesting a report via UI? Have you tested what happens when browser archiving is disabled / enabled? To make this universally work we might need to add some more features as it might work for this specific use case but not in another use case

Ok, I fixed code style notes.
As for side effect - my assumptions are that if plugin wants to change this behavior, it should take care of consequences of preventing single plugin archiving, and for second - only adding this hook shouldn't change anything.

I think that any plugins blocked from archiving with that hook will not be archived in future, as archive will be completed and closed, so only archive invalidation may bring a chagne here.
As it is this hook should not change anything. Only after some specific plugin hooks into it things may change, but again - plugin hooks into that event for a reason I guess.

If you see any specific cases needing attention right now, please let me know how to proceed with this addition?

Hi @mgazdzik

However for performance reasons it might be beneficial to prevent heavy plugin archiving under some circumstances to allow archiving run till the end (for ex. prevent actions plugin archiving, but allow remaining to process their data).

if your use case is to prevent heavy archiving of one plugin, when you skip a plugin archiving using this hook, how will you process this plugin's reports afterwards? Or do you not need the plugin's reports maybe?

As for side effect - my assumptions are that if plugin wants to change this behavior, it should take care of consequences of preventing single plugin archiving, and for second - only adding this hook shouldn't change anything.

IMO the platform should take care of it and not a plugin developer as it will be basically impossible for developers to do this unless it's intention is really to never archive a report eg for a specific site. Then the event has some right to exist without tackling these issues. In such a case we should maybe rename the event so the consequences will be clear for a developer (that it won't be archived at any time unless custom work is done)

In my case it is not necessary to process those missing plugins after archive is completed. It's that at given time it is necessary to disable certain plugin archiving (for ex. only disable actions archiving for month period for one site) and it's acceptable that this data will simply be missing, unless period is re-archived. However higher goal here is to allow all other periods/sites to finish archiving of given plugin.

As for event name I'm totally up for renaming. Maybe something like PluginsArchiver.shouldSkipProcessingReportsForPluginAndParams would do the job? Or maybe you have something in mind?

I was more thinking of something like PluginsArchiver.shouldSkipProcessingReportsForPluginAndAcceptMissingData but that's not really usable either.

I think to make this event useful it would be good to have the possibility to exclude certain reports from processing during browser archiving but still execute it while running on the CLI or to still include it in the final archive of the day. Like a parameter "$isFinalArchivingForGivenPeriod" but I think we might not know when this is. It would be a nice feature to sometimes ignore archiving some archives eg when requesting "today" via browser. Then we could eg only archive some reports every hour while some others are archived every 150s. In every case it would be useful to have a report in the "final" archive for that period though. It's not in your case the case :) but it would be much more useful for others this way.

Do you actually need the event or can you not take care of this in the plugin archiver class? You get all the parameters there etc. and could make it even easier testable this way etc.

Otherwise maybe an event name like PluginsArchiver.shouldNeverArchiveParamsForPlugin or PluginsArchiver.shouldNotArchiveParamsForPlugin. Ideally it could be done in the plugin archiver class itself until there is a better use case.

FYI: Maybe we could consolidate a couple of archive events under the same namespace (for Piwik 3 or Piwik 4). It's confusing to have so many different namespaces there.

My case is strictly related to preventing other plugins from archiving under certain circumstances.
Case you described with excluding certain plugins seems also worth considering, but from my perspective it's still up to what logic will be implemented within plugin using that hook, not the hook itself.

As for my specific use case - I have a plugin doing something, and during this plugin working I want a controll over what other plugins will be archived. For ex. I want to prevent 'Actions' plugin from processing when certain plugin setting is defined in my plugin. However, I still want to archive Actions plugin for other cases (some idsites, some periods, etc.), in which plugin will not block archiving. Also I want Action reports and API to be still available, which rules out way of disabling plugin.

I hope it clarifies a bit of what is my intention with that specific event. Please let me know which way of proceeding do you find most generic for the platform?

Hi @mgazdzik
we spent some time thinking about this and here is our suggestion:

Index: core/ArchiveProcessor/PluginsArchiver.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- core/ArchiveProcessor/PluginsArchiver.php   (revision 7ca14d216ea95cbce881867a4cb953b367fb7d85)
+++ core/ArchiveProcessor/PluginsArchiver.php   (revision )
@@ -14,6 +14,7 @@
 use Piwik\DataAccess\LogAggregator;
 use Piwik\DataTable\Manager;
 use Piwik\Metrics;
+use Piwik\Piwik;
 use Piwik\Plugin\Archiver;
 use Piwik\Log;
 use Piwik\Timer;
@@ -50,6 +51,7 @@
     public function __construct(Parameters $params, $isTemporaryArchive)
     {
         $this->params = $params;
+        $this->isTemporaryArchive = $isTemporaryArchive;

         $this->archiveWriter = new ArchiveWriter($this->params, $isTemporaryArchive);
         $this->archiveWriter->initNewArchive();
@@ -106,7 +108,7 @@
             $latestUsedTableId = Manager::getInstance()->getMostRecentTableId();

             /** @var Archiver $archiver */
-            $archiver = new $archiverClass($this->archiveProcessor);
+            $archiver = $this->makeNewArchiverObject($archiverClass, $pluginName);

             if (!$archiver->isEnabled()) {
                 Log::debug("PluginsArchiver::%s: Skipping archiving for plugin '%s'.", __FUNCTION__, $pluginName);
@@ -235,5 +240,18 @@
         $toSum = Metrics::getVisitsMetricNames();
         $metrics = $this->archiveProcessor->aggregateNumericMetrics($toSum);
         return $metrics;
+    }
+
+    /**
+     * @param $archiverClass
+     * @return Archiver
+     */
+    private function makeNewArchiverObject($archiverClass, $pluginName)
+    {
+        $archiver = new $archiverClass($this->archiveProcessor);
+
+        Piwik::postEvent('Archiving.makeNewArchiverObject', array($archiver, $pluginName, $this->params, $this->isTemporaryArchive));
+
+        return $archiver;
     }
 }

Index: core/Plugin/Archiver.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- core/Plugin/Archiver.php    (revision 7ca14d216ea95cbce881867a4cb953b367fb7d85)
+++ core/Plugin/Archiver.php    (revision )
@@ -121,6 +121,11 @@
         return $this->getProcessor()->getLogAggregator();
     }

+    public function disable()
+    {
+        // add flag 
+    }
+
     /**
      * Whether this Archiver should be used or not.
      *

we reuse the namespace Archiving http://developer.piwik.org/api-reference/events#archiving - and we let plugin developers either overwrite the object completely, or hook into and call ->disable() on the plugin archiver.

In the patch above we should also implement the disable() method (and add the flag in isEnabled()

And also document the event similarly to http://developer.piwik.org/api-reference/events#trackermakenewvisitobject etc.

If it sounds good to you please update PR and we'll get this merged for next release 👍

@mattab - I gave a thought to idea you described. So if I understand correctly, I should use that new hook in plugin and if logic fits - just call ->disable() on archiver object and Core will skip running it.
If that's correct, then I'm ok with that solution.

@mgazdzik Yes that's what we meant 👍 could you add a comment for the Event so the Event doc will appear automatically like on http://developer.piwik.org/api-reference/events#trackermakenewvisitobject

@mattab sure, I've just added phpdoc. Please let me know should I improve anything in phpdoc or is it ok?

@mgazdzik made minor suggestions in mgazdzik#1 - can you merge and then i'll merge this

@mattab PR merged, thanks for docs suggestions