Consider purging everything when a widget is updated

[danielbachhuber]

From #113

[rubas]

Widgets are used for sidebar, footers, etc but we are not aware where exactly.

Solutions:

• Manually clear edge after update
• Integrate custom logic on project basis for widgets
• Track where widgets use and emit surrogate key
• Clear edge automatically

[danielbachhuber]

See also https://github.com/pantheon-systems/pantheon-advanced-page-cache#adding-custom-keys

[rubas]

It's very likely that your widgets are affecting all most all your pages.

Widget/Menu gives the client the ability to do changes without having a dev at hand. It's not realistic that you replicate all the changes of the client in your custom cache logic for a handful of widgets.

Either you take the ability to do changes here away from the client or we need a more aggressive way to handle updates.

What about the compromise to emit on all dynamic request a special surrogate key and only purge that for widget/menu changes?

[danielbachhuber]

It's very likely that your widgets are affecting all most all your pages.

In some sites this may be true. On other sites this may not be. We don't know for certain.

Either you take the ability to do changes here away from the client or we need a more aggressive way to handle updates.

You could also set TTL to something like 60s and instruct the client they need to wait for the cache to expire. For a site like you're describing, this seems like an acceptable compromise — it doesn't sound like they need a high level of precision. They can always manually flush the entire cache if they want quicker results.

What about the compromise to emit on all dynamic request a special surrogate key and only purge that for widget/menu changes?

Could you describe this in greater detail?

[rubas]

If we start with low TTL caching again, then we don't need any cache keys, do we? And we are back in 2007.

As our options a limited with wp, I think its okay to go from time to time over the top and clear the whole cache instead of relying on a manual action or reverting back to a TTL based cache strategy.
There is a lot less harm done this way.

What about the compromise to emit on all dynamic request a special surrogate key and only purge that for widget/menu changes?

Emit on every dynamic page request (= everything that is handled by wp) a surrogate key like dynamic. We can use this to purge all „dynamic” pages and leave the cache for the static assets untouched.

[danielbachhuber]

If we start with low TTL caching again, then we don't need any cache keys, do we? And we are back in 2007.

Please be polite.

As our options a limited with wp, I think its okay to go from time to time over the top and clear the whole cache instead of relying on a manual action or reverting back to a TTL based cache strategy.

Your opinion is noted.

We can use this to purge all „dynamic” pages and leave the cache for the static assets untouched.

Makes sense. This is an interesting idea.

[joshkoenig]

We can use this to purge all „dynamic” pages and leave the cache for the static assets untouched.

Makes sense. This is an interesting idea.

I agree that's an interesting idea. It fits well with my notion of allowing an admin to make a choice about clearing their cache on #115.

If there were a wp-admin UI that facilitated making this choice we could direct people there, eg:

• Clear the whole cache (including images, css, and WordPress pages)
• Clear WordPress pages only

Is there also a case for only clearing the static assets? That's not possible now but we could add it fairly easily at the platform level.

This would also be worthwhile for us to port to the Drupal version of this for feature parity.

[rubas]

Is there also a case for only clearing the static assets? That's not possible now but we could add it fairly easily at the platform level.

It doesn't matter as long as Pantheon's default behaviour is to set max-age=31622400 on all static assets and bury them for a year in the local browser cache (Ticket #93151). 🙄

[rubas]

I assume that we are using a modern caching strategy with long TTL and only purging what has changed.

The TTL will be too long to just sit it out for a change. That means we are left with 2 options:

a) Emit necessary surrogate keys so that we are able to purge only changed content
b) Purge everything (or all dynamic content)

As long as you have not a) implemented, it doesn't really matter if you ask the admin to purge it manually or just do it for him. The cache has to be purged anyway.

The better strategy would a).

---

We now can either automatically add the surrogate keys or we have to implement the logic based on current configuration ourself.

But implementing the logic ourself also mean updating it every time somebody is changing the widget configuration. This is just not realistic, if you give a „client” access to this functionality.

As I don't know a way to implement it automatically with the current WP (ideas?), I would fall back to b) purge everything. And then we could do it just for them.

[rubas]

Don't forget to look at this from the end user/client/editor perspective.

The moment the client stops trusting your cache strategy, he will start to abuse this „purge all”-power and use it all the time (or/and demand low TTLs). And I mean all the time ...

That is why I prefer not to give the „purge all” power the client/editor in the first place and take care of everything automatically - having a proper a setup.

Purging one time too many does a lot less harm in the longterm.

---

If I purge only the dynamic content or everything doesn't really matter to me either as the one additional request for every static asset is not adding stress on the server on a project level.

On Pantheon level things could look different.

[danielbachhuber]

Widgets are being rebuilt as Gutenberg blocks in WordPress core, so this isn't an optimization worth solving for at this point.