Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.x] Make parent_uri and other entry data available in static caching invalidation rules #10233

Open
wants to merge 16 commits into
base: 5.x
Choose a base branch
from

Conversation

duncanmcclean
Copy link
Member

@duncanmcclean duncanmcclean commented May 30, 2024

This pull request makes it possible to use entry data as variables inside static caching invalidation rules, allowing you to configure slightly more advanced invalidation rules.

I've had a few sites in the past where I've wanted to invalidate URLs based on entry data. However, since there's no way for invalidation rules to be dynamic, I've had to opt for creating event listeners.

Here's a few examples where the ability to use variables in invalidation rules could come in useful:

  • In one of your templates, you output a list of any child entries.
    • When you update one of those child entries, there's currently no way to invalidate the parent entry without using a wildcard or creating a custom event listener.
    • With this PR, you'd be able to simply use {parent_uri} as an invalidation rule.
  • Let's say you have a Blog collection and each of those blog entries can relate to a Topic taxonomy term. Whenever you create/edit one of those blog entries, you want to invalidate the topic's "show" page.
    • Currently, when you update one of the blog entries, there's no way to invalidate the topic's show page without using a wildcard or creating a custom event listener.
    • With this PR, you'd be able to use /topics/{{ topic }}{{ slug }}{{ /topic }} as an invalidation rule.

No issue related to this one, just a small paper cut I ran into again recently.

@duncanmcclean duncanmcclean marked this pull request as ready for review May 30, 2024 17:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant