Question: Is it possible to include the date below posts in home and single layouts?

[dvhart]

• This is a question about using the theme.
• [?] This is a feature request.
• I believe this to be a bug with the theme.
  • I have updated all gems with bundle update.
  • I have tested locally with bundle exec jekyll build.

---

Environment informations

• Minimal Mistakes version: 4.8.1+
• Jekyll version: ?
• GitHub Pages hosted: yes
• Operating system: ?

---

Expected behavior

First off - wow, great work. A highly configurable theme that actually works with gh-pages. A rare gem... ahem...

I would love to be able to see the post date below the title in the home listing as well as near the top (instead of the bottom) in the single layout. I didn't find a way to do this in the docs, but hoping I missed it!

Steps to reproduce the behavior

Just visit any page:
https://dvhart.github.io

[mmistakes]

No way to do this via a config or setting. You’ll need to modify includes to reposition or add the date in different locations.

The home layout loops over the following include, so you’ll need to drop in the date Liquid/HTML there.

https://github.com/mmistakes/minimal-mistakes/blob/master/_includes/archive-single.html

[dvhart]

Thanks @mmistakes. I started the modifications and got something mostly working. One of the goals in using this theme was to minimize any changes to the theme and to keep it separate from my repository with a gem. Hoping I can find something that is minimally invasive and configurable that you might consider including. I'll share whatever I come up with. Thank you for the response.

[dvhart]

I've completed the overrides necessary to make this "work" for me. I've abused the page__meta class a bit to display both the date and the read-time. I'd like it to be smaller, and it doesn't work quite right with the archive tiles.

The home page now displays the date as well as the read-time. This could be smaller, and maybe gray or a lighter weight.

The same code displays now just above the content, regardless if overlay is used or not. This should definitely be smaller.

Finally, the "date read-time" doesn't wrap well in the archive post tiles, but the same code is used to create the wider home layout entries as these tiles, I wasn't sure how to go about that in a better way.

My solution is here dvhart/dvhart.github.io@05b076b, with my changes in comment blocks. I could submit these in a pull request to you @mmistakes if you're interested in discussing them and would prefer that mechanism. I know they aren't ready as they are, and they need some way to include configuration so that they don't break existing deployments of Minimal Mistakes. Are you interested in incorporating a configurable version of this? If so, I'm happy to do what I can - but I'm no designer, and this is my first time looking at jekyll and ruby. I have some very dated css experience.

[mmistakes]

Think this sort of thing is best left as an override. Not really comfortable adding in more config togggles for placement of the date. It opens up a whole can of worms I’m not interested in supporting.

[dvhart]

Thanks for your time @mmistakes, and for sharing your excellent work. I will look for ways to minimize my overrides, as having to override entire files like single.html is counter to the goals of using a gem theme and may pose a maintenance issue longer term. Perhaps that will lead to something which I can contribute back (no changes, just refactoring to minimize overrides). I'll close this one out.

[mmistakes]

It's a balancing act. Some things make sense to configure, while others stray from the aesthetic and goal of the theme.

Same thing happened to me years ago when I used someone else's theme. Eventually I outgrew it and wanted to take it in a different direction, where forking and/or building my own thing was a better solution.

[GregWoods]

Interesting discussion.
For the sort of time-sensitive programming blogs I read, I'm always infuriated when the post date is either not present or hard to find. If I'm reading about "embedded rust" for example, a three year old post is worthless. Date at the top. Always

[iBug]

@mmistakes I hope you could reconsider this. Post date is an essential piece of information IMO, and I would even favor this over what we have at present (read time). I've also overridden relevant files on my own similar to @dvhart (iBug/iBug-source@a92a7a1, iBug/iBug-source@de736bda) just for this. I don't see much harm adding an extra configuration key like I did for my website as there's already a dedicated key for showing read time.

[ryan-p-randall]

I totally agree that most customizations are better left as overrides, @mmistakes. Like some others here, I think the original post date is one slice of information important enough to not be left to an override.

As a college librarian, I'll just add that one of the most common models for teaching students to evaluate online sources begins by asking when the post / page was published. Having the updated time at the bottom is important—and also indicating the original date at the top would make every site using this theme appear more authoritative to all the students taught to use this model.

Here's a couple examples that emphasize looking for time indicators on websites. The main term librarians use for this is "currency":

• North Michigan University shows the most succinct way this is usually taught.
• Washington State University shows the more verbose / nuanced way this is usually taught.

Whether or not you reconsider, thanks as always for such a great theme!

[dvhart]

Wow, 3 new requests all of a sudden. I did add my own override. At some point in the past (I haven't been doing much with the blog) the clock icon stopped working and I haven't yet looked into what changed. I'm sure it's trivial, but this is the kind of breakage it would be nice to be able to avoid by integrating this option with the theme. @mmistakes if you're of a mind to reconsider now with additional interest, I'm certainly still keen to see this integrated.

[GregWoods]

"Not really comfortable adding in more config toggles for placement of the date" - I agree. Don't provide options for placement of the date. You decide if it goes in, and where it goes in, it is your theme.
A pet hate of mine is programs with 1000 different options. It generally comes from developers who cannot make a design decision, and so they hand the decision over to the user. It sounds good in theory, but "option-overload" is a bad thing. I call it "Linux Geek Design".

I, and some librarians it seems, consider post-date vital, and as theme designer, you decide where it goes. It is much more important than the trendy "time-to-read".
If your decision as designer is not to include it in the theme, that is your call. I respect it.
I'll be modifying a local version of the theme for myself, which I'm a little disappointed at, just because theme updates will be that little bit more difficult. But, your theme is so good, and has saved me a lot of time when refreshing my old blog, that I believe it is worth it.