Show date of posts

[limjh16]

This is an enhancement or feature.

Summary

Adds an optional "date" alongside the read time in _includes/read_time.html

As a result of this change, I renamed read_time.html to post__meta.html

Context

To enable the date, it is similar to enabling the read time, just set show_date to true in _config.yml

Date only screenshots

Date+read time screenshots

[iBug]

Looks exceptionally awesome! I like it. Not sure what @mmistakes thinks though, as he's been resistant to adding extra configurations (ref).

[iBug]

For the file name, I suggest post__meta.html as it's clearer than "rtsd", which is pretty obscure per se.

[limjh16]

Looks exceptionally awesome! I like it. Not sure what @mmistakes thinks though, as he's been resistant to adding extra configurations (ref).

Woops, should have done a check to see whether others have suggested this before... sorry about that
Also, thanks for linking that issue, I realised I missed out editing _includes/page__hero.html from there...

[iBug]

It seems like there's no need to differentiate between page and post - posts are a subclass of pages so using page.whatever everywhere would just suffice. This can simplify a lot of the logics around and also eliminate the need to pass an extra p variable to {% include %}.

[limjh16]

Hey, I had tested that before but in _includes/archive-single.html page.whatever doesn't work. Whenever the archive-single include is called, it's usually in a for-loop where something is assigned to the post variable, that's probably why the page variables doesn't work in that case

[iBug]

I would probably do something else like {% assign page = post %} before including the new file in the case you described. Or maybe {% assign page = page | default: post %} at the top of the new file. Or maybe {% assign post_date = page.date | default: post.date %} or something similar. Differentiating between variables makes the code less maintainable.

[mmistakes]

The complexity comes from site.pages, they don't have dates generally. This is the big difference between posts and pages/collections. Can't assume the user will add a date to the YAML front matter either which can really start to complicate your Liquid spaghetti code.

If I were to consider adding dates inline with read time I'd do it like my other themes e.g. So Simple or Basically Basic.

[iBug]

@mmistakes It could be documented. Jekyll supports parsing date from the yyyy-mm-dd-post-title.md filename format even for documents other than those in the _posts collection (e.g. custom collection). If the entire ecosystem around this theme's setup is properly documented, I'd say I see no problem implementing this - it's a vital piece of information for a post as iterated multiple times by multiple users in #1428.

Anyways, whatever feature that a lot of people find useful, I‘m probably for it.

[mmistakes]

@iBug That's fine. To your point about reducing complexity. I'd suggest looking how I did it in my other themes, it's very similar to your suggestions. Basically normalize the variable names with assigns, then they can be piped through 1 include.

Simplifies the logic so you can do: If site dates are enabled and the document has a date set then show date. If read time is enable show that. Instead of if post... do this... if page do that like the original PR had.

[limjh16]

doing {% assign page = post | default page %} seems to work, thanks for the suggestion @iBug!

[iBug]

I think it's better to put post date before read time for being more intuitive.

[iBug]

@mmistakes Any ideas? This PR is at a perfect state now, even better than I could imagine. As discussed multiple times before, many users of the theme are in serious need of post dates on their websites. It's not hard to imagine that more users will happily enable it if it's easily available. I understand your view on "fewer configurations", but something so important like post date is definitely worth it.

[iBug]

Can we anticipate this fantastic feature in MM v4.20? 😊

[thoemmi]

I'm waiting for it too, as I'd like to customize it to show tags as well.

[mmistakes]

Finally got around to checking this out. Couple of small things then I think it's ready to merge in:

• Adjust spacing between datetime and read time.

The | doesn't have enough space between it and looks like it's part of the time. My suggestion would be to do something like <span class="sep"></span> instead. Then the following CSS which would allow someone to override the character and spacing easily without having to touch the _include.

.sep::before {
  content: "\2022";
  padding-left: 0.5em;
  padding-right: 0.5em;
}

• Add documentation about how to enable dates... perhaps before the Reading time config here.

• Add a sample post with the date enabled similar to the reading time posts to show an example and for testing purposes.

[iBug]

To give more details on @mmistakes' sensible suggestions, you'll want to add the following changes:

• Replace your current separator (a plain vertical bar) with an empty span: <span class="sep"></span> and use the CSS ::before pseudo-element to fill in the content and set the spacing. You'll want to add mmistakes' sample CSS in _sass/minimal-mistakes/_page.scss, under the "Page meta" section, probably right before the next section "Page taxonomy" (the blank line at L301), as shown below.

  minimal-mistakes/_sass/minimal-mistakes/_page.scss

  Lines 277 to 279 in 8a60d43

  	/*
  	Page meta
  	========================================================================== */

• Add documentation in docs/_docs/05-configuration.md. You can compose the docs in a way similar to the "Read time" paragraph. Just follow the styles and you're good to go. Don't forget to add a screenshot (you can simply add the one in mmistakes' comment).

  • You can even copy that paragraph and replace the content. IMO sentences, codes, etc. should remain the same, so just swap the keywords out and it'll be OK.

• Sample post: Copy the one mmistake linked and change the front matter. You may consider creating two copies, one with only post date enabled, the other with both.

[limjh16]

Any reason why? I would think editing the yml file would be easier, especially since the breadcrumb_separator option is in there too

[iBug]

The YAML file can't be edited in parts, which means you have to copy the whole file in order to override a single key. Using _config.yml would be even better, though I still prefer the CSS solution.

[limjh16]

Hmm, @mmistakes what do you think? It would be very simple to change it to use _config.yml and CSS anyways.

Also, I'm not really sure how you make the preview images, could you maybe help to make them? 😅

[iBug]

A side note: It would be desirable to select-and-copy the full breadcrumb path including the separator, while it probably makes little sense to copy post date and reading time along with the separator. Using a CSS ::before pseudo-element makes sure it's not selectable (which is how CSS-based Font Awesome icons work).

[iBug]

@limjh16 If you have Jekyll locally installed (along with Ruby and Bundler), you can run bundle exec jekyll serve in the docs directory, which will open up a development server at http://127.0.0.1:4000/minimal-mistakes/ for you to preview the whole docs site locally. You can then take the screenshots from your browser.

[iBug]

AFAICT that's the built-in screenshot utility in macOS. For this specific PR I think it's fine to take a screenshot with whatever you have - you're not trying to illustrate the whole page layout after all.

[mmistakes]

I wouldn't worry about adding a screenshot. I think a description is clear enough what the feature is. Just as long as the documentation is there to explain how to toggle it on or off I'm cool.

It can always be improved later with a screenshot if needed.

[iBug]

@mmistakes What about the implementation of the separator element? There have been 3 suggested in the thread:

1. The current approach, using text from _data/ui-text.yml as a text node
2. Similar to 1, but using text from _config.yml (probably with a default value) as a text node
3. Use an empty inline element (e.g. <span>) and apply CSS on its ::before pseudo-element

My personal preference is 3 > 2 > 1, though any would be fine if it's easy enough to switch to 3 without overriding too many files (viva la CSS!).

[mmistakes]

I prefer in the same order you proposed.

3. since that's the method I suggested 😉 and it keeps the separator text out of the markup since it's decoration and not necessarily content. Going the CSS path also adds way more flexibility if someone wants to change the separator in different context... (e.g. use a bullet on archive pages, use a pipe on post pages) which you can't do if it's hardcoded in the HTML.

2. Is fine and matches how title separators are treated. Advantage over 3, it's "easier" to change by the user as they don't need to override any CSS which tends to be a show stopper for many. Disadvantage, the separator is in the HTML markup and there's more Liquid bloat introduced in the templates.

1. Least desirable. Need to add a key for every language in the UI text data file versus a single key in _config.yml that's treated as a global variable.

[limjh16]

I have changed the customisation to a CSS implementation

[iBug]

This is great! I've examined locally and the CSS solution is flawless!

[iBug]

@mmistakes This is looking perfect now (to me). Any chance you could take a look?

[tobiasvl]

Thank you for this feature!

My page suddenly wouldn't build anymore (because I hadn't pinned a version number, it automatically used the latest version...), and after some digging I found out that the reason it broke was that read_time.html had been removed, which I used to – you guessed it – implement this exact functionality. Hehe.

👍

[the-physicist]

I really liked it, you did a great job! Thank you.