Cache invalidation for scheduled Entries

[ostark]

Problem: Scheduled Entries do not purge the cache automatically.

Idea

A console command keeps an eye on entries.postDate and entries. expiryDate. This command must be scheduled via cron to invalidated the cache without human interaction.

[sjelfull]

We just discussed this on the Craft Slack.

For Craft 2 I did this plugin.
For Craft 3, I think i'm going to port it and convert it into using delayed jobs instead.

[ostark]

Perfect! @sjelfull

[joshangell]

So I’ve been thinking about this too, for Craft 2 I did a wider agnostic approach with Scheduler that does this but can also be extended to do anything else, like email someone a reminder in a week or whatever.

[joshangell]

The conceptual issue I’m having with delayed jobs in a queue is that what if the server gets rebooted or whatever, do they stay around? Can they be scheduled for a long time is the future, like a month or whatever?

I appreciated you could use SQS or whatever, but there’s something nice and safe about a row in a db.

[ostark]

@joshangell thanks for your input.
@sjelfull I'm not sure if delayed jobs are appropriate for this as you never get Jobs out of a queue, e.g. in case the editor decides to change the expire or publish date. Maybe this is not a big issue.

[sjelfull]

@ostark Doesn't matter. You just publish a new job, and in the service you check if the entry is published/expired.

[ostark]

Ok, @sjelfull, I'm happy to depend on your plugin 👍
Do you know if plugin-plugin dependencies are possible with Craft 3 anyways?

[sjelfull]

Craft does not support it directly, but you can suggest/require your own dependencies, and they will be installed by composer.

[sjelfull]

Pushed initial version in https://github.com/sjelfull/craft3-publishedevent

[ostark]

In Upper 2.0

php craft upper/scheduled

Added 29e4ec5

[RedLucas]

In Upper 2.0

php craft upper/scheduled

Added 29e4ec5

I just found this, and it seems to solve a problem I've been having. I see it's been merged into develop. Any change of getting it into a minor release in the near future?

Or I guess an Upper 2 release.

[ostark]

2.0 is a completely different code base. It's better than the 1.0 code, but also not completely happy - it's actually 2 years old.
I'm looking forward to bring Upper to the next level this year.

[timkelty]

@ostark For expiryDate, I was thinking we should probably be able to handle it without a cron.

When we're listening for elements to add their tags, if they have an expiryDate, we could compare it to the default for the Cache-Control: max-age header. If it is sooner, we update the value for max-age.

[ostark]

@timkelty what if we have a list with multiple elements?

[timkelty]

@ostark as it iterated through the elements, it would just update the soonest expiry date (if it was sooner than the default)

[timkelty]

@ostark Craft now does this natively for its own cache: craftcms/cms#11901