GitLab

Introduce CLI command to purge events

Improve messages, making them translatable. Also, simplifies how $dry_run is checked, reducing duplication.

Includes basics of a purge command

Purge completed events more frequently

Fixes #13

Purge completed events more-frequently

Fixes #13 

Purge completed events more-frequently, in case site has sufficient volume that there are large quantities to remove

Fixes #13

When an event's timestamp--or other data--is invalid, remove the entry

When the timestamp, action, or instance are corrupted, the REST endpoint will list the event, but it won't be able to run it. As a result, the event remains perpetually in a broken state because its identifying information isn't reliable.

Slow post ID growth and improve Internal Jobs

This mainly impacts the process for marking events completed

Update internal jobs creation

Fixes #17

Set internal events on more-appropriate hooks, particularly one that doesn't run for all front-end requests

Hooking on `rest_api_init` may be a problem, but since this plugin is predicated on the REST API, it seems equally foolish _not_ to.

Fixes #16

Update entries, rather than deleting and re-creating

Stops plugin from artificially and unnecessarily inflating post IDs, for one thing.

Fixes #14

Table name shouldn't be hardcoded, though Core usually figures it out

This doesn't seem to have caused any significant issues, but it did trigger an occasional warning that I'd lost in other noise.

Detect and suppress duplicates

Detect and remove duplicate events

Fixes #7

Turns out, there's no harm in letting it run for CLI commands

Improve caching and event CPT handling

Plugin needs to create entries before `init`, and expects a certain `post_name`, warranting this approach

Update CPT entries directly, rather than through Core's cron functions 

Add native caching

Reduces possibility for race conditions when multiple jobs run at once

Until now, the CPT has been an independent part of this plugin, something that theoretically could've been disabled without impacting plugin functionality. However, race conditions prevent the plugin's use without the CPT, so it must be integrated more-deeply with the event-execution portion of the plugin.

Since we often query directly, it was foolish of me to omit this both because Core's caching is often bypassed, and because it won't be reliable.

Like we do when checking if a job exists, retrieving jobs should also query directly to avoid caching such as what Advanced Post Cache provides.