Configure entries layout list or grid

[TarodBOFH]

This is an enhancement or feature.

Summary

This allows to use grid layout on page.entries_layout on the home layout.

Context

There is support for layout grid on most places but home page.

I mimicked how it's done on posts/categories/tags to allow that on home page. See demo at www.cornerinthemiddle.com

Included a break since when using grid the post images are too close to the horizontal line bellow posts text.

There's a entries div now surrounding the posts since the first row of the grid was having a slight padding on the left. The home now behaves like posts/categories/tags pages with grid but including the paginator.

Tested on mobile renders ok and on hd desktop, for best results on desktop we can use classes: wide and paginate: 4 on _config.yml (or multiples of 4 if you want more rows)

[TarodBOFH]

Probably there's a better way to add some padding / space but I've not done front-end / css in years :P

Please if you like this PR but think there's a better way to add this space, don't ask me to fix this line 😳

[mmistakes]

Yeah definitely not a fan of the empty <p></p> element. Styling should be achieved with CSS, not forcing in HTML elements for presentation purposes, it's bad for semantics.

As @iBug suggested, there are enough class name hooks that I'm sure a simple line of CSS can add some margin to increase the white space.

[TarodBOFH]

Thanks for the tip. I added 0.5em instead to minimize the differences with previous versions (i.e. with lists) while keeping a small visual space between the horizontal line and the posts.

Hey mom see, I'm doing frontend again! :D

[iBug]

The <p></p> margin solution looks OK to me (as I would also do so if I were to implement this), but I'm sure @mmistakes won't be happy this way. A better approach would be to update the CSS and set margin-bottom of the element right above to a reasonable value.

In _sass/minimal-mistakes/_archive.scss, at line 35, the margin-bottom attribute of the "Recent Posts" text is currently set to zero (3rd value of margin, see W3schools).

minimal-mistakes/_sass/minimal-mistakes/_archive.scss

Lines 34 to 36 in d5d3863

	.archive__subtitle {
	margin: 1.414em 0 0;
	padding-bottom: 0.5em;

You can change it to 1em and remove the empty <p> tag, which will result in an appearance like this:

That should look better IMO.

[TarodBOFH]

The <p></p> margin solution looks OK to me (as I would also do so if I were to implement this), but I'm sure @mmistakes won't be happy this way. A better approach would be to update the CSS and set margin-bottom of the element right above to a reasonable value.

In _sass/minimal-mistakes/_archive.scss, at line 35, the margin-bottom attribute of the "Recent Posts" text is currently set to zero (3rd value of margin, see W3schools).

minimal-mistakes/_sass/minimal-mistakes/_archive.scss

Lines 34 to 36 in d5d3863

	.archive__subtitle {
	margin: 1.414em 0 0;
	padding-bottom: 0.5em;

You can change it to 1em and remove the empty <p> tag, which will result in an appearance like this:

That should look better IMO.

As I replied, thanks for the tip. It's working nice now. I went for 0.5em instead of 1, enough space to not have images stretching up to the horizontal line:

Mobile:

edit: uploaded sample images

[mmistakes]

Nice work @TarodBOFH, everything looks good to me.

[TarodBOFH]

Raising here the comment @mmistakes but it seems that the grid layout got broken on the last build.

Items are haivng only the first item as class grid__item while the next ones are list__item

I'll have a look on the cahnges on 4.20 that might have caused that

[TarodBOFH]

This is what it renders with the entries layout on home;

This is what it rendered with the layout grid prior the 4.20 release. Did something went incompatible today?

[mmistakes]

I'm not seeing anything in 4.20.0 that could have broken this.
Something else might be at play. include.type is grid on the first item in the for loop, everything else is nil. Which is why they're inheriting the default value of list.

I'm pretty sure I tested the PR and it worked, but I'm a bit foggy on it now.

I've hit this before with for loops and I think we'll need to pull it out of that and assign the variable before. Inside the for loop when you're calling page.entries_layout it's looking for that front matter in each of the "posts/pages" in the loop... not the home page where you added entries_layout: grid. So that's why they're all nil.

[mmistakes]

This fixes it. I'll push an update

{% assign entries_layout = page.entries_layout | default: 'list' %}
<div class="entries-{{ entries_layout }}">
  {% for post in posts %}
    {% include archive-single.html type=entries_layout %}
  {% endfor %}
</div>

[TarodBOFH]

I was opening a bug, I've to leave now so probably won't be able to fix till tomorrow, I've updated my site to use a specific commit has of the remote theme, Ill have a look later. Thanks! (I'll keep the bug open).

The funny thing is that the behaviour happens also on the posts and categories pages but was not happening before (those are also inheriting the layout from home).

PS> I wont submit the bug then. We're realtime chatting. Thanks!

[mmistakes]

Not able to reproduce on posts and categories, but it should be fixed for home.html layout.
Looks like if you try to read page. variables inside of a for loop unexpected things happen. Not sure why that changed but maybe there was a Jekyll version bump that affected it.

Assigning that variable outside the loop in the proper context seems to fix the issue.

[TarodBOFH]

It is still happening on the posts and layouts pges (home works however)

If I remove the grid from the home, posts and categories pages still broken.

[TarodBOFH]

I'm going to leave you a branch to experiment (has dockerfile for jeckyl if you want to fast deploy the site) that reproduces the error without customizations.

[TarodBOFH]

https://github.com/TarodBOFH/tarodbofh.github.io/tree/mm-bug-with-grid-layout

no entries_layout: grid defined on frontmatter == posts and categories broken and home list as expected
entries_layout: grid on frontmatter == posts and categories broken bug home is working

There are two commits on that branch that you can test. I need to go now, sry. ttyl8r

//cc @mmistakes

[mmistakes]

Nevermind, I see it on posts.html and cateogories.html layouts too.
I'll just apply the same fix to those layouts.

Only thing I can think of that's breaking this now is a Jekyll version bump. Perhaps with all the caching stuff they added there's some Liquid weirdness going on. That grid stuff has been in the posts layout for some time and the only thing that might have touched those includes were the post date stuff added in 4.20.1. And I don't see how that could have broken it.

[TarodBOFH]

Nevermind, I see it on posts.html and cateogories.html layouts too.
I'll just apply the same fix to those layouts.

Only thing I can think of that's breaking this now is a Jekyll version bump. Perhaps with all the caching stuff they added there's some Liquid weirdness going on. That grid stuff has been in the posts layout for some time and the only thing that might have touched those includes were the post date stuff added in 4.20.1. And I don't see how that could have broken it.

Don't think the jeyll version bump as my dockerfile has a fixed jekll version. I also don't see what might have broken it; I was looking for some post-date assiging something to the variable include.type or something like that but I am no liquid expert.

Thanks for the effort mate. You've earned a beer or dinner if you come to Madrid.

[mmistakes]

I'm stumped as to what could have broken it then. Maybe something in the Liquid further up the page is clobbering the page. variables... who knows.

For now the workaround of pulling those values out of the for loop seems to work.

[TarodBOFH]

Got it. It's this line on the posts date {% assign page = post | default: page %}

[iBug]

Got it. It's this line on the posts date {% assign page = post | default: page %}

That discovery was rather difficult but you made it! Now I know how to fix it properly.

In short: Use another variable name to avoid clobbering the page variable.

Looks to me like swapping post with page in that whole include file would work as post is not an "automatic" object in Jekyll.

Something like sed -Ei 's/\<page\>/post/g' post__meta.html then editing the first line.

[mmistakes]

Good find @TarodBOFH.

[mmistakes]

@iBug I already pushed some fixes before discovering this bad assign above. Not sure if it's worth reversing those commits and applying some sort of fix to {% assign page = post | default: page %}. I have no idea if this has other side affects elsewhere we haven't caught yet.

I feel like there was somewhere I had to build in logic around date as things broke in page or collection documents that aren't posts. Or maybe I'm just confusing it with one of my other themes.

Point being, we'll need to test this better as I know there's some edge cases in there.

[iBug]

I see little value in reverting that fix (v4.20.1) if it proves effective, though the status quo is far from optimal, as overriding a built-in object is particularly prone to errors. But it's always safe to use another name (object maybe?) if you're afraid of breaking other parts.

Edit: I just checked the whole repository: All post.* attribute access are contained within a for post in posts loop, so it should be safe to change the post date into assign post = post | default: page, as far as I can tell.

Look through grep -nrE '\<post\>\.' --exclude-dir={.[a-z]*,_site,node_modules,docs,test,vendor} (Bash) if you want to find it out for yourself.

[mmistakes]

Thanks @iBug. I'm going to take a good look and likely refactor the new post meta/data stuff that was just added. I really should have taken a better look at that PR as I'm finding some other things that could be cleaned up... inconsistent class names/include name, dropping in <br /> for styling purposes instead of using CSS, etc.