eleventy: `page.date` is not accurate when github action is used to deploy to server.
Describe the bug
page.date is not accurate when github action is used to deploy to server.
To Reproduce Steps to reproduce the behavior:
- I have this
footer.njkthat is included (using{% include 'footer.njk' %}inbase_layout.njkandhansreich_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 - This work really well on my local machine and the date is reflected correctly.
- 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 --checksumto 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!
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 32 (5 by maintainers)
@clockshark Please remember that eleventy is FOSS, and that the people who work on it have other priorities.
#142 is shipping with Eleventy 1.0.1.
Specifically this comment https://github.com/11ty/eleventy/issues/142#issuecomment-1043605312
The docs will have the new feature after the next build: https://www.11ty.dev/docs/dates/#setting-a-content-date-in-front-matter
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.
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??
@brycewray glad you found something that works for you!
Straight JS might be even easier than a templating language. 😊 good luck!
@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).
@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.
yes, you are right!! I was thinking something like:
setting up in a global data or something.
I see, you are saying something like this:
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!
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.