Support LATEST_POST and SITE_TIME keywords in last_modified_at front matter

[tsjensen]

This is a little PR which adds an enhancement to the last_modified_at front matter value in pages. Currently, the value of last_modified_at in a page's front matter can only be a time stamp. With this PR, it can also be one of these values:

• SITE_TIME – placeholder for the time of the latest Jekyll run (actually the value of site.time)
• LATEST_POST – placeholder for the date of the most recent post

Especially the latter is very helpful for a "What's new" page, which shows a list of recent posts. This "What's new" page will update whenever there is a new post, and by specifying last_modified_at: LATEST_POST, our sitemap can reflect that.

I also added a line to the Gemfile adding tzinfo-data, in order to enable running the tests on Windows.

Let me know if anything is unclear, or I misunderstood something. Thanks for considering this!

[RDIL]

Cool, Thanks!!! Looks like a nice feature :)

[pathawks]

I see the value in this feature, but I wonder if this plugin is the best place for it. It seems to me like the last-modified-at plugin is the logical place for this to go.

[tsjensen]

@pathawks I was thinking of Github Pages users, who can‘t use last-modified-at.

[ashmaroli]

This doesn't make sense to me. Inside a forloop through site.html_pages, instead of printing the last modified time attribute of the current page in the iteration, print the attribute of a document in the posts collection... ?

Sorry. Closing..

[tsjensen]

Ok, after leaving this hanging for two years, this time the decision was quick. Faster than Travis.

I think I explained the use case (think "What's new page"). It feels kinda bad to get a PR closed while it was still unclear to you what the PR was about. I spent an hour or two putting it together (it was just very small, but still), so you might have spent a minute or two understanding what it was about.

[tsjensen]

For anyone coming this way looking for a solution, you can move from GitHub Pages to GitLab Pages. GitLab is less restrictive with static site generators, you can use more Jekyll plugins (such as last_modified_at), or even completely different site generators.

[ashmaroli]

@tsjensen Once again, sorry for rejecting your proposal.

I understood your use case pitch about "What's New?" page being updated with the latest post.. which is similar to (or the same as) having an index.html page rendering a list of all posts in the site. Whenever a new document is added, the index page updates its contents at build time.

But what didn't feel right to me is proxying the post's datestamp as the index page's datestamp in the sitemap by using a keyword.

If a custom modified time has to be rendered, one should just provide a datestamp via the front matter attribute last_modified_at. (The referenced plugin just automates this and some more..)

[tsjensen]

Ok, thanks for taking the time to explain.

You are basically right, one can use last_modified_at front matter to manually set a hard-coded date. As it stands today, one would have to manually update this value on the "What's new" page every time a new post is published. Or, I would have to use the jekyll-last-modified-at plugin, but that plugin is unavailable to GitHub Pages users. (Only on GitLab is this possible.)

With the LATEST_POST keyword, which one could place in the front matter as shown, the automated way would be opened up on GitHub Pages, without needing the extra, forbidden plugin. Also, as long as the two new keywords are not used, nothing changes, right?

In other words, without this PR, the "What's new" page forever shows the timestamp of its construction, not the timestamp of its most recent content, and that is semantically a bug.

[ashmaroli]

shows the timestamp of its construction, not the timestamp of its most recent content

I think it is an inherent flaw with static site webpages that reference content from elsewhere.. On modifying your example slightly, say What's New references a new document added to a collection recipes instead of posts.. Having the keyword LATEST_POST then serves no purpose.. Or say, the page references documents from multiple collections — posts, news and recipes..

Also, supporting one use case puts another the base use case in jeopardy — A site with 500 non-whats-new site.html_pages would have to check for the two rarely occurring keywords before hitting the default branch for each page...

[tsjensen]

Ah, the recipes example makes a good point! I hadn't thought of that.
Still, it could be fixed by changing the keyword to LATEST_POST_collectionName, where collectionName would be posts, news, or recipes, e.g. LATEST_POST_recipes. That probably wouldn't cover the "multiple collections" case, but that one seems to be rather theoretical in nature.

Would you accept this change if I made the collection name dynamic?

[tsjensen]

Never mind. I slept on it, and I think you understand the use case now. If you still don't want the feature, that's your decision.

I moved my active projects from GitHub to GitLab already, anyway, so I'm no longer really constrained by this problem.