Using Last-Modified and 304 Responses in Evolution CMS

Adding a Last-Modified header is one of those classic optimizations that sounds trivial but only works well when you understand what date you are actually publishing to the browser or crawler.

The goal is simple: if the visitor already has the current version, Evolution CMS can answer with 304 Not Modified instead of sending the full page again. That reduces bandwidth and helps crawlers revisit large sites more efficiently.

The original implementation used OnWebPagePrerender, read the current document’s editedon value, checked HTTP_IF_MODIFIED_SINCE, and short-circuited the response when nothing changed.

if (isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])
    && strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) >= $last_modified_time) {
    header('HTTP/1.1 304 Not Modified');
    die;
}
header('Last-Modified: '.gmdate('D, d M Y H:i:s', $last_modified_time).' GMT');

The more subtle part is keeping related pages fresh. If a listing page depends on several child documents, editing a child may also need to bump the effective date of the parent listing. That is why the original discussion also suggested a companion update plugin to touch selected resource IDs after save or duplication events.

Used carefully, this is still a strong optimization for editorial sites with stable content and predictable cache rules.