[mattstauffer]

TL:DR: The 2026 archive page is sending a Last-Modified header based on when 2026.php (the template file) was last modified, not based on when there is actually new articles. This PR fixes that.

---

We ran into a local cache issue on the archive pages:

https://www.php.net/archive/2026.php sends a Last-Modified header based on the mtime of the 2026.php script file. But new articles are data (news entries), not edits to that file, so publishing one never the file's mtime and therefore doesn't advance Last-Modified, which means it's currently been set to August 10 since the last modification of that file.

A returning browser then revalidates with If-Modified-Since set to that frozen date, always matches, and gets 304 Not Modified. That means the browser keeps showing the stale archive forever. Only a hard refresh (which omits If-Modified-Since) reveals new articles.

This is all about how the origin emits Last-modified and how the browsers process it, and has nothing to do with the CDN.

So, the fix:

Set Last-Modified to the newer of the most recent article's publish time or the page's file mtime. This way, both new articles and template edits bust the local cache. I extracted this into a news_archive_last_modified() helper in layout.inc and applied it to 2026.php.

[naderman]

LGTM, assume this would fix the local cache issues indeed

[sy-records]

Thanks