page.date is not accurate when github action is used to deploy to server.

[khoivan88]

Describe the bug
page.date is not accurate when github action is used to deploy to server.

To Reproduce
Steps to reproduce the behavior:

1. I have this footer.njk that is included (using {% include 'footer.njk' %} in base_layout.njk and hansreich_base_layout.njk) in all of my page (700+ pages) with intention of having 'last updated date' for pages that have been modified only: https://github.com/khoivan88/organicchemistrydata/blob/3452915650c34be52ba299c586e1474ebe340116/src/_includes/footer.njk#L4
2. This work really well on my local machine and the date is reflected correctly.
3. However, when I used this github action to deploy to my remote server, the date on each page seems to be the last time the github action was run. I even used rsync --checksum to compare the content and the output of rsync seems to only have transferred changed files. However, the date seems to be changed for all files https://github.com/khoivan88/organicchemistrydata/blob/master/.github/workflows/build_and_deploy.yml

You can see the result of rsync result of one of the builds here, under 'rsync deployment', it shows only 1 file was transferred: https://github.com/khoivan88/organicchemistrydata/runs/848026787?check_suite_focus=true
Yet, in the sitemap here: you can see pretty much all of the files were changed to that date: https://organicchemistrydata.org/sitemap/sitemap.xml

I know that 11ty has mentioned this issue in the common pitfall but I'm not sure there is a way for me to set 'Last modified' date for every single of my 700+ pages automatically?

Expected behavior
When deploying using github action, either 'created date' and 'modified date' not changed for unchanged files

Would anyone has any suggestion for me where I don't have to put date for each file?

Thank you so much!

[cj81499]

Could this be a timezone issue? I think GitHub actions run on servers using using UTC time.

[khoivan88]

hi @cj81499 , it could be but I used rsync -vzr -rlD --checksum --omit-dir-times and based on rsync output, only a fraction of files were sent my my remote server, yet, it seems that all files on the server have a new date, which is really weird to me??

[cj81499]

I'm not particularly familiar with rsync's many options, but since rsync doesn't change file contents, the problem must be within eleventy, or your specific use.

How is the date different? Is it always off of your local time by the same amount?

Also, if setting a last modified date would fix the problem you could write a script to update each file's frontmatter, or create a global data file called date.js that exports the string "Last Modified"

[khoivan88]

Yeah, I'm not sure it is an issue particularly because github action spins up a new VM machine everytime it builds and I am just trying to find a way to go around my issue.

So in my layout, I used {{ page.date }} which supposed to give the created date of the file (which is fine for me for now). It is not that the datetime is off by a certain hour, it is just not the correct time.

Say i have 2 files:

• page1.html
• page2.html,
  and both were created on July 1st, 2020.

At this point, the date on each page is 'July 1, 2020'. A couple of days later, say 'July 5', I update page2.html, at this point, my desired outcome is the date on page2.html 'July 5, 2020' while for page1.html is still 'July 1, 2020'.

This works perfectly fine on my local machine but on my remote server, which is the destination of the github deploy action, both page1.html and page2.html are now 'July 5, 2020' even though I only change the content of page2.html.

I hope this explanation is clearer than the previous one!!

I'm not sure if created a global data to access last modified date would help because it seems that the last modified date on the Unix system on my remote machine for all pages are changed, even though rsync output does not seem to transfer those files. I feel like I'm missing something here!

[cj81499]

That's much clearer, but I had another realization. git does NOT preserve file creation and edit time (see here for the reasoning behind this). Therefore, when you checkout the files in the github action, the creation/modification date will not match the time on your local development machine. My best advice is to explicitly include dates in metadata or file names.

[khoivan88]

yeah, I'm afraid that is something I might have to do, but even then, because as you said the file meta data is not preserved, I think it would still be wrong :(!!

[cj81499]

metadata is not preserved. Frontmatter is not metadata.

[khoivan88]

yes, you are right!! I was thinking something like:

---
date: Last Modified
---

setting up in a global data or something.

I see, you are saying something like this:

---
last_updated: 2020-07-10
---

Man, I was hoping that could be automated because of the large amount of files I have. Thank you very much for all of your suggestions. I really appreciate it!

[cj81499]

Happy to help 😄

Write a script to add that frontmatter based on your local metadata! Don't do it by hand!

[khoivan88]

@cj81499 thank you for your suggestion about the script. Hmm, I am just a newbie with JS but maybe I can add some script into .eleventy.js to automate running that script on build? 😄

[brycewray]

@cj81499 On a slightly related subject: even if deploying straight from Git master to one's host (Netlify, Vercel, etc.), should we therefore avoid putting times in posts' front-matter-based dates, so as to avoid the whole $MyTimeZone -> UTC issue? Since webmentions like to see time-of-day in the date, I have been including it up to now but any dates with times past midnight UTC show up as the next day (I am in U.S. CDT).

[cj81499]

@khoivan88 That's not quite what I meant. Something that runs at build time will not be sufficient. When you building on the remote server, the data will not be in place.

Instead, you could write a script (separate from eleventy) that traverses the files in your project, reads their metadata, and updates the file frontmatter of the file.

You would run it once, instead of you manually updating the many files in your project.

[cj81499]

@brycewray interesting question!

Best I can think of is writing a nunjucks or liquid filter for outputting time correctly.

Services such as Netlify and Vercel typically set environment variables (For example, I believe Netlify sets NETLIFY=true) In your filter, you can check the value of process.env.NETLIFY to get different behavior when running locally vs on a remote server.

You'd have to consult the documentation for the static host you're using to see what environment variables are available.

[brycewray]

@cj81499 I already have a support request into the host right now to find out, so hope to know soon. Thanks.

[cj81499]

@brycewray have you check their docs? The variables they set are almost surely documented.

[cj81499]

@brycewray

Netlify: https://docs.netlify.com/configure-builds/environment-variables/#read-only-variables

Vercel: https://vercel.com/docs/v2/build-step#system-environment-variables

[brycewray]

@cj81499 I have, but couldn’t find anything about time zone settings:

• https://vercel.com/docs/configuration
• https://vercel.com/docs/api

[cj81499]

@brycewray I'm not suggesting there's a way to change the time zone of the machine you're building on.

Instead, you can detect the build is on Vercel's servers by reading environment variables and using a nunjucks/liquid filter that corrects for the time zone difference (or does nothing if the environment variable is not set).

[brycewray]

@cj81499 Aha. Gotcha. Well, in my site's case, would be straight JS, but I get your point. Will see what I can do. Thanks again.

[cj81499]

Straight JS might be even easier than a templating language. 😊 good luck!

[brycewray]

@cj81499 After spending a few hours researching and trying alternatives, I decided to stop fighting it and, instead, simply adopt UTC for all my posts’ dates. Between Eleventy’s own UTC-ishness 😄 and that of my host — and, indeed, that of most hosts out there — it seemed to be the course of least resistance.

[cj81499]

@brycewray glad you found something that works for you!

[clockshark]

How come when we post something on this gihub no one ever replies. I have made at least 4-5 issues and none of them have every been replied too. We even posted one asking for PAID help. All messages as well to the authors have never been responded too as well??

[khoivan88]

How come when we post something on this gihub no one ever replies. I have made at least 4-5 issues and none of them have every been replied too. We even posted one asking for PAID help. All messages as well to the authors have never been responded too as well??

I honestly don't know. I think with some more establish products like this, the developers might be busy with other projects??

[cj81499]

@clockshark Please remember that eleventy is FOSS, and that the people who work on it have other priorities.

[Ryuno-Ki]

Instead, you could write a script (separate from eleventy) that traverses the files in your project, reads their metadata, and updates the file frontmatter of the file.

In case somebody wants to run this, use fs.fstat().
Since there would be a file descriptor anyway, the frontmatter could be updated.

Instead, another idea might be to go with a *.11tydata.json file for that file since JSON is easier to parse.

[Ryuno-Ki]

How come when we post something on this gihub no one ever replies. I have made at least 4-5 issues and none of them have every been replied too.

Sorry to hear that.
I grew up with a Netiquette, that asks to stay silent if I don't know the answer. I could imagine that this could be the case here as well. Or people simply busy with life.

[khoivan88]

Instead, you could write a script (separate from eleventy) that traverses the files in your project, reads their metadata, and updates the file frontmatter of the file.

In case somebody wants to run this, use fs.fstat().
Since there would be a file descriptor anyway, the frontmatter could be updated.

Instead, another idea might be to go with a *.11tydata.json file for that file since JSON is easier to parse.

Hi @Ryuno-Ki , thank you very much for your suggestion, I have just started with node.js since using 11ty about 1 month ago so I will need to look into how to use fs.stat. For your second idea of, because I have 700+ pages and only want the Last updated content updated on the files that were changed so I don't think that your second idea would be easier than the first, right?

[Ryuno-Ki]

It's one idea, actually.

Goes by:

1. For each directory
2. Find all files in that directory (resp. go to 1 for a subdirectory).
3. For each file
4. Get the fs.stat of that file and write it to the basename with .11tydata.json extension.
5. Commit all those JSON files into version control.

If you don't like callback-syntax, wrap them into promises with es6-promisify.

If you need some assistance, I'd need to know more about your file structure.

[khoivan88]

@Ryuno-Ki Thank you very much for your further info.
I will have to read some and try what you suggested to see if this would work. In my case, this is further complicated by involvement of other contributors that are somewhat less technical inclined and therefore, I have been relying on Github Action to run the 11ty build process!

[zachleat]

See also #142

[zachleat]

#142 is shipping with Eleventy 1.0.1.

Specifically this comment #142 (comment)

The docs will have the new feature after the next build: https://www.11ty.dev/docs/dates/#setting-a-content-date-in-front-matter