When a GravityForm is updated, purge the page cache of pages that contain the form

[stduerre]

Feature summary:

At the moment, when a GravityForm is updated, the old version is still being served from caches. Editors have to manually go to the pages that contain the form and save them again, which triggers a cache delete. It's a manual process that editors often forget, resulting in us serving old content.

This feature would automatically purge all caches of the pages that contain the form whenever a form is updated. That includes local cache on the server (object cache) and CDN/Cloudflare caches.

Proposal & Constraints:

Here's a first proposal for a solution.

• It hooks into the gform_after_save_form
• Finds all pages that contain a GravityForm block
• Finds the subset of pages that contain the current form
• Uses wp_update_post to save those pages. Saving triggers the cache to be deleted in the same way as editing and updating the page would.

I also did some research into other solutions and clearing the cache directly. The Cloudflare plugin we use doesn't support clearing page cache programmatically. Cloudflare does have an API that could be used, but it's more complicated, needs more maintainance and we'd have to manage API keys to use it. Local caches would have to be treated separately. That's why simulating a page save is my preferred solution, it's much simpler and requires less maintainance.

In my tests, I could not find any side effects. I didn't notice a change to the post, not even a new revision.

Additional context:

A discussion about performance would be interesting. It would be much better if we could find the blocks (only those with the correct formId) directly through WP_Query instead of going through all posts that contain a gravityforms/form form block and filter for the formId. I couldn't get that to work yet, regular expression searching seems to be only possible on meta values of posts, not the content.

[lithrel]

Looking good :+1: two things to add:

• we could also take reusable blocks into account (so probably querying reusable blocks for those using GF, and then querying posts using those)
• we have a custom block search (used for the Block report beta) that can also support search in block attributes (to a certain extent :grimacing: ) so we could narrow and speed queries that way

[stduerre]

we could also take reusable blocks into account (so probably querying reusable blocks for those using GF, and then querying posts using those)

Good point! Totally makes sense to include reusable blocks.

we have a custom block search

Ah yes, that looks promising for better performance :slightly_smiling_face:

[comzeradd]

Thanks @stduerre for the detailed proposal. Feel free to open a PR directly in the master-theme when ready.

[stduerre]

PR is ready for review/discussion. It now also finds the form block when they are used within reusable blocks.