feat: Add garbage collection cleanup admin and cron job

[markkelnar]

Fixes #217

Add admin settings interface to toggle (checkbox) enable/disable a daily wp cron event which when run, delete saved queries meeting criteria of age.

Add a number field in admin settings representing the number of days old, once reached by a saved query, it is deleted.

Add 'Groups' for saved documents. These groups are ignored by garbage collection.

[jasonbahl]

I think my preference for this to be MVP should be:

• a way for individual queries to opt out of garbage collection
• batch the garbage collection (instead of posts_per_page -1)

[markkelnar]

Some screen shots of adding the 'Garbage Collection' option in the admin editor.

[jasonbahl]

I pulled this down to walk through it and check out the code.

I wanted to make sure it played nice with all the PHPStan changes, so I merged main into this branch and ran composer check-cs and composer phpstan.

PHPStan

A couple changes required. Also see: https://github.com/wp-graphql/wp-graphql-smart-cache/actions/runs/5804611542

PHPCS

Passes 🙌🏻

---

Unexpected Behavior

I went to test some things, and it looks like maybe we have some gaps in logic.

It appears that old posts, not associated with any "group" are not being deleted as expected.

Steps to reproduce:

• In GraphQL > Settings > Saved Queries, enable garbage collection and set the number of days to 1:

• Publish 2 posts of the "graphql_document" post type. Add a "group" taxonomy term to 1, but not the other. Set the dates in the past more than 1 day (I set the dates to June 9 and April 9, both far beyond the 1-day setting value)

• Using WP-CLI, Run the cron event wp cron event run wpgraphql_smart_cache_query_garbage_collect

• See that neither document is deleted (I expect the one without a group to be deleted)

NOTE: if I generate many posts of the graphql_document type with the following command wp post generate --post_type=graphql_document --post_date="2022-11-14 20:00:00" and then run the cron event, those generated documents delete. But the manually created document with no association to a "group" is still hanging around.

I also generated some persisted queries by pointing wpgraphql.com's Faust codebase with the Persisted Queries Link at my localwp instance with this version of WPGraphQL Smart Cache active, and I got it to generate a query via APQ.

I modified the date of the query to June 9:

Then I ran wp cron event run wpgraphql_smart_cache_query_garbage_collect and the persisted query created by APQ was NOT deleted. I expect this APQ generated document, which has no association with a "Group" tag, and is 2 months old, to be deleted.

So, there's some bugs in the logic here. I've not yet dug into it, but the first place I would probably look is the WP_Query that determines which posts to delete.

(fwiw, I also checked out sha 3a7f1413dd080e5b4761b6510e6a872437b1943d from July 28, the state the PR was in before I merged the phpstan changes to this PR, and the same behavior occurs. I wanted to rule out any regressions that might have happened due to the phpstan changes, and I've confirmed the behavior documented above is the same with or without the phpstan changes merged in)

[markkelnar]

@jasonbahl try changing the post_modified_gmt date. This is what determines the age of the saved query, not the publish date. Per the discussion in the original issue.

[jasonbahl]

@markkelnar ah ha! Updating the modified date does indeed do the trick. 🤦🏻‍♂️

I tested by manually updating the post_modified date in the database for a persisted query that was generated by APQ and running wp cron event run wpgraphql_smart_cache_query_garbage_collect again.

I think it would be good at some point, to have some UIs that show when a persisted query will "expire". 🤔 Will think about it and open a new issue for future discussion.

[jasonbahl]

I opened this issue as a follow-up to work on at some point in the future: #245