Feature Request: Custom expiration time for Posts/Pages

[liphenom]

Feature that allow you to set another expiration time for posts/pages only, because post page don't change that much. It can help to reduce load on server.

[raamdev]

@liphenom Thank you for the feature request. I'll add this to the todo list.

[jaswrks]

I think having a separate expiration time could get hairy. While the Post/Page content itself might not change, other portions of a Post/Page introduced by a theme could definitely need to be refreshed; even after what might seem like a small tweak. That's the nature of page caching.

I guess having an option for site owners who prefer it is OK, so long as it doesn't make things overly complex; or introduce a feature to a novice site owner that might not realize the full implication of doing such a thing. Overall though, I see this as a very rarely-used feature.

[ronnieg303]

Re: the comment about something changed in a theme. Page/post content could also be affected by plugin activation or deactivation. When that happens, it seems the effect would or could be site wide, so QC may need to have a hook somewhere that any plugin activation/deactivation and/or theme settings change might prompt/suggest a manual page cache purge by the admin/user, then let the admin/user decide to purge cache or not.

[raamdev]

@ronnieg303 Quick Cache already detects many such changes and figures out when it should clear the cache. For example, when you switch your theme, Quick Cache detects this and wipes the cache.

However, I'm glad you brought these issues here as there are a few other features/todos that should have Issues opened for them.

I've opened two GitHub Issues related to your comment above:

• Option to prompt admin before performing site-wide wipe of the cache
• Prompt admin if cache should be wiped after activating/deactivating a plugin

[raamdev]

Including comments from #302 (so that it can be closed in favor of this issue):

@ronnieg303 writes...

Enhancement Request:

I have a large website where the content of pages in certain folders is database driven. The database gets refreshed overnight, and all database updates are done by a specific time early each morning. At that time each day, I would want all cached pages in those specific folders to be auto-purged. It appears I should be able to do that by simply removing the applicable QC cache folders under /wp-content/cache/ etc. with a cron job, but that makes it OS and web server specific, and beyond the technical abilities of most users.

@raamdev writes...

@ronnieg303 There is a feature request open for this already: Feature Request: Custom expiration time for Posts/Pages. It sounds like being able to specify a Custom Expiration for Posts/Pages is what you need, i.e., if you set Pages to expire at 6am each day, any future requests to those pages would trigger them to be re-cached (old cache file removed, new cache file created).

Is that what you would need?

Quick Cache already has its own way of purging cache files after a specific amount of time. This is referred to as the Expiration Time (see Dashboard → Quick Cache → Plugin Options → Directory / Expiration Time). This setting ensures that cache files don't become too stale, however this setting applies to all cache files. If you have an expiration time of 7 days, then Quick Cache will make sure a cache file doesn't live longer than 7 days after it was generated.

It sounds like you'd like a way of setting a custom expiration time (e.g., every 7 days), or a specific recurring date/time (e.g., every day at 6AM) for a specific set of Posts/Pages, is that correct?

@ronnieg303 writes...

Correct. Add recurring expiration day / time for specific folders/files, similar to cron setups. Different folders could have different expiration times, depending on other site and database functionality.

[raamdev]

Including comment from #482 (so that it can be closed in favor of this issue):

@ronnieg303 writes...

Add an optional cache expiration override parameter to urls in the ACE other urls list. So if a url in that list, and it also has a cache expiration override, that expiration time would override the global ZC cache expiration time for that specific url. For example:

/myfolder/myurl/,24h

Reason: Some urls, and specifically urls in the ACE other urls list, may need to be refreshed and re-cached more or less frequently than the site default cache expiration time. In my case, most urls on my site are fine with a 14 day or even 30 day expiration time, since they rarely if ever change. But some need to be refreshed and re-cached daily, since their database driven content changes daily. Setting the global cache expiration time to 24 hrs for all urls, which I have to do now, creates unnecessary server load to process every url on the site every 24 hrs, when only a select few urls need to be refreshed that often.

This was from a feature request for an Auto-Cache Engine feature that I feel should not be part of the Auto-Cache Engine but rather part of the new Expiration Time settings that should be added as part of this GitHub Issue.

In addition to setting a custom expiration time for Posts and Pages in general (globally), it would be nice to have the option of setting a custom expiration time on a per-post/page basis, so that some posts/pages could be set to expire at different times than others.

We might even include a text box where an advanced site owner could provide a list of URLs with a specific format that includes the custom expiration time, as shown in the example above. That would be very useful for site owners who need to set custom expiration times on many posts at once.

---

@jaswsinc writes...

I think having a separate expiration time could get hairy. While the Post/Page content itself might not change, other portions of a Post/Page introduced by a theme could definitely need to be refreshed; even after what might seem like a small tweak. That's the nature of page caching.

I think there's some misunderstanding here. A custom expiration time for a post/page would have no effect on higher-level auto-purge/clear routines. If there were a hundred pages with different expiration times and a new plugin was installed, the entire site cache would still get wiped (assuming this hasn't been manually disabled--we have feature requests open to improve this behavior as well; see #307 and #308). The point being, a custom expiration time simply means the cache for that specific post/page is only allowed to live a certain amount of time, after which a future request will generate a new cache of that page.

[jaswrks]

The point being, a custom expiration time simply means the cache for that specific post/page is only allowed to live a certain amount of time, after which a future request will generate a new cache of that page.

Copy that. I understand. I don't see a problem with this then. However, I stand by my original comment, this is going to be rarely used and it has the potential to create confusion. Not just for site owners, but for anyone assisting a ZenCache customer. Being able to set a custom expiration time is fine, but when you write in for assistance and you have custom expiration times set for a variety of pages and don't fully understand how this works, things begin to get hairy; i.e., more difficult to debug.

Anyway, I do see the value in such a feature. I'd give this a priority of 2/10 though. Or, perhaps it would be easier to implement this as a Filter in WordPress, and then provide an article that explains how to prepare a map of Posts/Pages to expiration times.

[raamdev]

things begin to get hairy; i.e., more difficult to debug.

This is easily resolved by providing more debugging information inside the cached files themselves. For example, if there's a custom expiration time applied to something, the cache file could indicate that at the bottom in the debugging notes. Related to #292.

I do see the value in such a feature. I'd give this a priority of 2/10 though. Or, perhaps it would be easier to implement this as a Filter in WordPress, and then provide an article that explains how to prepare a map of Posts/Pages to expiration times.

Yep, that would work too. A WordPress Filter might be a better way to go. If there's a greater demand for a UI for this, we could reconsider adding a UI.

[renzms]

To further extend on this feature request, it would also be nice to be able to set different automatic expiration times for different taxonomies.

---

Referencing internal ticket: https://websharks.zendesk.com/agent/tickets/12422

[raamdev]

Requested here: https://wordpress.org/support/topic/shorter-cache-expiration-time-for-the-homepage/

[renzms]

Requested here:

Internal Ticket