Issue: Content Health Freshness does not consider lastmod field #775

Closed
opened 2026-10-05 03:04:50 +02:00 by adam · 2 comments
Owner

First of all - thank you for the incredible work you put into Front Matter CMS. It is a fantastic tool and a joy to use every day.

This is a minor thing, but I noticed the freshness calculation seems to use the date field rather than lastmod when determining content age. I could be wrong about the root cause, but the behavior I am seeing is that a post updated today (with lastmod set to today) is still flagged as 654 days old - which matches the original date value.

For example, a post with date: 2024-09-22 and lastmod: 2026-07-09 is flagged as "654 days old - consider refreshing" even though the content was just updated today.

To Reproduce

Open a post that has both date and lastmod in frontmatter

  • Update the lastmod field to today's date (indicating a content refresh)
  • Open the Front Matter CMS dashboard
  • Navigate to Content Health → Freshness

The post is still flagged as stale based on the original date value

Expected behavior

When a lastmod field is present and more recent than date, the Freshness calculation should use lastmod to determine content age. This reflects the actual freshness of the content - a post that was recently reviewed and updated should not be flagged for refreshing.

Device:

OS: Windows 11
Front Matter CMS Version: 10.11.0
Visual Studio Code (latest stable)

Additional context

Is there a setting I am missing that controls which field the freshness calculation uses? If not, it might be worth considering lastmod as the basis for freshness when present, since refreshing content does not always mean writing a new post. Sometimes an older post is still relevant and valuable to readers, but needs updated screenshots, revised commands, or adjustments to reflect current product behavior. In those cases, my natural workflow is to update the existing post and set lastmod - not to create a replacement from scratch.

Thanks
--Jesper

First of all - thank you for the incredible work you put into Front Matter CMS. It is a fantastic tool and a joy to use every day. This is a minor thing, but I noticed the freshness calculation seems to use the `date` field rather than `lastmod` when determining content age. I could be wrong about the root cause, but the behavior I am seeing is that a post updated today (with `lastmod` set to today) is still flagged as 654 days old - which matches the original date value. For example, a post with `date`: 2024-09-22 and `lastmod`: 2026-07-09 is flagged as "654 days old - consider refreshing" even though the content was just updated today. ## To Reproduce Open a post that has both date and `lastmod` in frontmatter - Update the `lastmod` field to today's date (indicating a content refresh) - Open the Front Matter CMS dashboard - Navigate to Content Health → Freshness The post is still flagged as stale based on the original date value ## Expected behavior When a `lastmod` field is present and more recent than `date`, the Freshness calculation should use `lastmod` to determine content age. This reflects the actual freshness of the content - a post that was recently reviewed and updated should not be flagged for refreshing. Device: OS: Windows 11 Front Matter CMS Version: 10.11.0 Visual Studio Code (latest stable) ## Additional context Is there a setting I am missing that controls which field the freshness calculation uses? If not, it might be worth considering `lastmod` as the basis for freshness when present, since refreshing content does not always mean writing a new post. Sometimes an older post is still relevant and valuable to readers, but needs updated screenshots, revised commands, or adjustments to reflect current product behavior. In those cases, my natural workflow is to update the existing post and set `lastmod` - not to create a replacement from scratch. Thanks --Jesper <!-- github-sync-id:4846837369 -->
adam closed this issue 2026-10-05 03:04:50 +02:00
Author
Owner

Thanks @dotjesper, you are correct. In the beta, a change has been implemented to do the checks as follows:

  1. content type datetime field with isModifiedDate
  2. content type datetime field with isPublishDate
  3. date field
  4. publishDate field

#1044

Thanks @dotjesper, you are correct. In the beta, a change has been implemented to do the checks as follows: 1. content type datetime field with `isModifiedDate` 2. content type datetime field with `isPublishDate` 3. date field 4. publishDate field #1044 <!-- github-comment-id:4933153907 -->
Author
Owner

Released in version 10.12.0.

Released in version 10.12.0. <!-- github-comment-id:5371145896 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#775