feat: support on-demand revalidation via graphql_purge#3810
Merged
Conversation
Adds a dedicated guide showing how to listen for the graphql_purge action and trigger framework-level revalidation (Next.js as the running example), covering key formats, key-to-path translation, per-request batching, and header-based webhook auth. Also fills in the matching stub in extending.md.
Receives webhook POSTs containing { paths: string[] } and calls
res.revalidate() for each. Authenticates via the
X-WPGraphQL-Revalidate-Secret header (constant-time comparison)
against WPGRAPHQL_REVALIDATE_SECRET env. Validates path shape and
caps the batch at 100 entries; failures are reported per-path
without aborting the request.
Pairs with the on-demand revalidation guide added to
wp-graphql-smart-cache. The 5s ISR fallback in
getTemplateStaticProps is intentionally left in place until the
on-demand path has been validated end to end on production.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
With on-demand revalidation now wired up via /api/revalidate, the 5s ISR window obscures verification: any change appears fresh within seconds even if the webhook never fired. Bumping to 5 minutes makes on-demand the only path to near-immediate updates while still providing a bounded stale-window if the webhook silently fails.
Pass `path` as a positional %s argument to console.error rather than interpolating it into the format string. Template literals aren't real format strings, but keeping user input out of the format-string slot satisfies CodeQL and is a tidier pattern regardless.
The previous edit overloaded the 'Purging in response to a custom event' section with content about *listening* to graphql_purge, but that section's original intent was the opposite direction: how plugins with custom tables can *emit* purge events when their own data changes (mirroring what Invalidation.php does for core WP types). Restores the @todo with a sketch of what it should cover, and splits the on-demand revalidation pointer into its own dedicated section.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
docs/on-demand-revalidation.md) that walks through using thegraphql_purgeaction to drive on-demand revalidation in static frontends — covering key formats, key-to-path translation, per-request batching, and header-based webhook auth, with a Next.js example.websites/wpgraphql.com/src/pages/api/revalidate.tsthat receives{ paths: string[] }, authenticates viaX-WPGraphQL-Revalidate-Secret(constant-time compare againstWPGRAPHQL_REVALIDATE_SECRET), and callsres.revalidate()per path with per-path failure reporting.docs/extending.mdso the new page is discoverable from there.The 5s ISR fallback in
getTemplateStaticPropsis intentionally not changed in this PR. Once the on-demand path is verified end to end on production (with the WP-side mu-plugin from the docs example), a follow-up can bump it to ~300s as a safety net for any CMS changes Smart Cache doesn't track.No code is shipped inside
wp-graphql-smart-cacheitself — only docs. The intent is to validate the pattern via dogfooding before deciding whether any of this should be packaged into the plugin.Test plan
{ revalidated, failed }shapeMY_REVALIDATE_SECRETandWPGRAPHQL_REVALIDATE_SECRETto matching values, save a post, confirm the affected page rebuilds without waiting for the 5s ISR windowrevalidatefrom 5s to ~300s once on-demand is confirmed working