Add dependency on jekyll-last-modified-at

[aepstein]

Add jekyll-last-modified-at to make it easier to time stamp built pages. Currently this requires us to do a static build locally, but it seems like a feature that would be widely used.

[benbalter]

@gjtorikian, any strong opinions here?

[parkr]

:+1: :heavy_multiplication_x: :100:

@aepstein :wave: from a former Cornell student!

@benbalter There might be some security concerns around the files passed to git, but I'm sure they can be adequately mitigated.

[gjtorikian]

Unfortunately, this plugin simply does not work on GitHub Pages: https://github.com/gjtorikian/jekyll-last-modified-at/issues/32

We've looked into it; the Pages instance only clones with a depth of 1. You'll need to build this locally and push it up, as with other plugins.

[ghost]

That's strange. I just used it on an item in a collection today and it only updated the last modified date for that one item. I left a comment here: https://github.com/gjtorikian/jekyll-last-modified-at/issues/32

I feel it would be very beneficial to have this plug-in as a part of the Pages gem.

[ghost]

@parkr would you mind reopening this until there's been some further investigation?

[gjtorikian]

This PR should go up to 1.0.1; not sure if you have the time for that @aepstein.

Things have changed so much in the last couple of years that this may be working again. Who knows, let's found out!

[benbalter]

@gjtorikian will this work with a shallow (e.g., --depth 1) clone?

[gjtorikian]

will this work with a shallow (e.g., --depth 1) clone?

I truly have no idea.

@jhabdas' comment is:

I started using this gem yesterday and can confirm, at least for collections, it pulls the timestamp from the individual asset.

I hate to pull the "not my team!" card, but, I am pretty busy at work at the moment and don't have the time to give this a thorough testing. Mostly because I am no longer sure how the internals of Jekyll/Pages work.

[parkr]

We pull with --depth 1 and I can confirm that this breaks expected behaviour (i.e. in all cases the date is the exact same since we're only working with 1 commit of history). We clone with that depth to make builds faster and to improve reliability on our systems, so the potential path forward here would be to make use of the Git API and fetch the date of the latest commit on that file. It would be terribly inefficient if you did this for every page, however. Perhaps we could add this to the site.github gem (jellyll/github-metadata) as site.github.commit_dates[<filepath>] and read them all in bulk from the GraphQL API. Is that possible, @gjtorikian?

[ghost]

Aside: My testing was not on GH Pages, but using Git itself with a Cloud CMS for editing from a Web-based GUI which preserves individual file history.

[gjtorikian]

Is that possible, @gjtorikian?

It should be technically possible. Moreover, right now, given a Git tree, you could list all the entries in that tree via GraphQL. I don't know if that's useful though.

[jimkohl]

Thanks Pat for the references. Apologies for the unnecessary issue!

--depth 1 will just grab branch tips and unless I'm missing something that will work ok for publishing purposes.

So I brought this into my local jekyll and it seems to be grabbing the timestamps correctly.

But it adds a bunch of time to startup as noted. However I'm wondering if it would be possible to whitelist as-is until said optimization above is avail (great idea and willing to assist).

That way we could still use it in the interim. Thoughts?

[ghost]

Taking a fresh look at this. Modified dates are a fundamental part of the web and should be worked into core for majority benefit—not just GH pages.

[divadsn]

Highly awaiting this gem to be working, it should be a basic thing in times of modern websites. :smile:

[jayvdb]

Note there are some very serious problems with the plugin, especially its test suite, that need fixing before this should be whitelisted or added as a dependency. See PRs and issues that I have raised in its repo.

[fingolfin]

I made an update version of this PR (see here for the relevant tree), but then realized this issue is still blocked by the fact that git rev-parse won't work as desired in the GitHub Page settings, due to shallow clones being used.

And it seems https://github.com/jekyll/github-metadata/issues/130 also went nowhere so far (due to a lack of volunteers with the time and skills to implement it, I guess). Pity :-(