Page MenuHomePhabricator

Introduce a parser function that allows editors to define a maximum cache validity interval for a page
Open, Needs TriagePublicFeature

Description

Feature summary:

Introduce a {{CACHEREFRESH:...}} parser function that allows editors to define a maximum cache validity interval for a page, triggering automatic cache invalidation at a specified frequency.

Use case(s):

Some wiki pages display content that changes depending on external factors but is not directly tied to edits, making normal cache invalidation insufficient.

A concrete example is the Main Page on Latin Wikipedia, which displays a daily “Pagina cottidiana” (“Article of the Day”). The selected article is automatically updated after midnight based on a pre-generated queue of featured pages. However, because the page output is cached by the system and the cache is not always refreshed promptly, outdated content can be served. This may result in issues such as the same article being displayed for multiple days or the next scheduled article not appearing as expected.

Currently, this issue is mitigated by manually purging the page cache (e.g. via a purge button or manual action) after midnight. This is fragile and requires human intervention every day, which is neither scalable nor reliable.

Benefits:

This feature would allow editors to declaratively specify cache refresh constraints directly in wikitext, removing the need for manual purging and reducing reliance on operational workarounds.

It would improve reliability for pages with time-sensitive but regularly scheduled content (e.g. Main Pages, portals, rotating highlights, or other templated daily/weekly content).

The proposed syntax could be like the following:

{{CACHEREFRESH:hourly}}

{{CACHEREFRESH:daily}}

{{CACHEREFRESH:weekly}}

{{CACHEREFRESH:monthly}}

etc.

The {{CACHEREFRESH:...}} parser function would expand to an empty string more or less like {{DISPLAYTITLE:...}} does.

Since it could be inserted by templates and these can require conflicting refresh rates, if multiple {{CACHEREFRESH:...}} declarations are present in the same page, the most restrictive value (i.e. the shortest cache interval / highest refresh frequency) should take precedence without generating errors.

If set to daily the refresh should happen every day at midnight, if set to hourly the refresh should happen at the top of each hour (e.g., 00 minutes past the hour), and so on. Optionally, future extensions could allow specifying an exact time within the interval:

{{CACHEREFRESH:daily|14:32:24}}

Event Timeline

Grufo updated the task description. (Show Details)

However, because the page output is cached by the system and the cache is not always refreshed promptly, outdated content can be served. This may result in issues such as the same article being displayed for multiple days or the next scheduled article not appearing as expected.

The problem, already reported in T119366, T351573, etc., is likely deeper and unlikely to be solved by yet another parser function, when the existing parser functions correctly indicate cache TTL, and it still does not work.

reported in T119366, T351573

I don't know how deep this goes, but from the linked threads it seems that certain time-related parser functions can affect the refresh rate. That implicit behavior seems difficult to reason about. For example, if I have {{#time:Y-m-d|now}}, I probably wouldn't want an hourly refresh, whereas I definitely would for {{#time:j xg Y H:i:s|now}}. And there can be much less trivial cases than these. Wouldn't a dedicated parser function provide a simpler and more explicit approach, without requiring the parser to infer the best refresh rate?

I am not saying there is no use or demand for the feature you are proposing, nor that it would not make things clearer, only that introduction of a new parser function is unlikely to solve the problem of serving expired pages.

For example, if I have {{#time:Y-m-d|now}}, I probably wouldn't want an hourly refresh

Indeed, this changes only at midnight, because of the "d".