Hey @patrick_here, thanks for checking out Surge!
The way Surge works is it collects some information during each request, about which posts, pages, and other post types are queried during that request. This information is then saved to the cache metadata, and next time a post is updated, Surge will know which requests are now invalid and should be regenerated. \
Similarly, when a post (or other post type) is transitioned between draft/pending and publish states, cache is marked as expired and is regenerated during the next request.
However, there will always be some edge cases occasionally, and I’ll be happy to further look into and add support in Surge for a specific plugin that you’re working with.
Let me know!
Hello Konstantin,
Well at the moment I’m not sure I need a caching plugin but perhaps I could in the near future. Anyway the specific scenario I had in mind was in connection with the “Spiffy Calendar” plugin …but many calendar plugins have similar functionality. With this plugin it’s possible to have a little list of “today’s events” showing up on the front page (implemented via a widget inserted into a sidebar). Here’s how it works when the widget is activated on the site:
Whenever a visitor requests the home page the plugin does a long, nasty database query on the plugin’s database table. If, for example, it is 11:59pm on Monday night and there are no events configured for Monday then no events will show in the “today’s events” area of the sidebar. But if it is a minute past midnight on Tuesday and an event is configured in the “Spiffy Calendar” plugin for Tuesday then the long nasty query will come back with one or more events and now the home page will look different; it will include this new event for Tuesday.
It’s hard for me to imagine how any caching plugin could accommodate such a scenario unless there were some kind of handshaking logic between the caching plugin and the calendar plugin.
