@tsteur sorry to bother, If I understand correctly, this issue is differentiating the CLI and the browser request on Archives jobs. When the browser triggers it, it should pass the setting already set by the admin. But through CLI it won't need that check?

I'm not sure if it will need that check or not on CLI. That would be part of the issue to figure that out. Generally it be great if we could remove this line $_GET['trigger'] = 'archivephp'; completely. Or if it was added for purgeOutdatedArchives, maybe it could be set only in that task and then unset again if it did not already exist before that.

I would probably start with removing $_GET['trigger'] = 'archivephp'; completely and checking if tests still pass. If that's the case, I would look into why purgeOutdatedArchives could possibly need that flag to trigger archiving and whether it might be safe to just completely remove it.

The goal will be to not have trigger=archivephp during scheduled tasks as this can have unexpected consequences like all tasks triggering archiving etc.

@tsteur Would this completely prevent scheduled tasks from triggering archiving for specific plugins? For example a user recently had an issue where the IP2Company plugin was launching archiving when the scheduled tasks executed. Due to the configuration of the plugin it seems to rely only on archiving triggered by the scheduled task.

Would this completely prevent scheduled tasks from triggering archiving for specific plugins

AFAIK yes it would stop that. Plugins shouldn't archive data during scheduled task as this can have big performance and memory implications. The plugin could probably workaround it by setting $_GET['trigger'] = 'archivephp'; in the scheduled task (and ideally unset it after it's finished)