Trigger static caching rules when entry unpublished

[stuartcusackie]

Apologies if this has been requested already.

I have rules to invalidate all entries when my primary navigation changes, however, if an entry within my primary navigation is unpublished then the caching rules are not triggered. This is because the navigation has not been directly edited, yet technically it has been edited by other means.

So I wonder if the core can be updated to:

• listen for 'published/unpublished' changes in entries
• check if the 'published/unpublished' entry is part of any navigation
• If it is then trigger the static caching rules for that navigation

I know this can be achieved with custom invalidation rules but I think this should be how it works by default.

Thanks!

[duncanmcclean]

This should be the case already - it's working for me w/ full-measure static caching.

When I mark an entry as unpublished, the entry's "show page" is invalidated and so is the collection "index page" (which is part of my static caching invalidation rules).

If this isn't working for you, please open a bug report and we can take a further look. Thanks!

[stuartcusackie]

Maybe it's a case of being on an old version. It's 4.50.0

Or maybe I'm not explaining it correctly. It's not that I want the cache of my index page wiped, I want every page listed in my caching rules for the navigation wiped:

'navigation' => [
  'primary' => [
    'urls' => [
      '/*'
  ]
],

So say my 'about' page appears in my 'primary' navigation, then the static cache should be wiped for all pages (/*), not just an index or home page. The primary nav has changed from unpublishing an entry contained in it, therefore the rules above should be triggered - all urls should be wiped.

[duncanmcclean]

Ah, I see... that makes sense! Re-opened.

[ryanmitchell]

@stuartcusackie take a look at: https://statamic.com/addons/thoughtco/cache-tracker - it may do what you need.

[stuartcusackie]

@ryanmitchell Looks very useful, thank you. I'll try it out someday.

[duncanmcclean]

Actually, it looks like you submitted a feature request for the same thing last year.

Closing this issue in favour of #976.