Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

page.layout should reflect the requested layout in all circumstances #1934

Open
benbalter opened this Issue · 18 comments

9 participants

@benbalter
Owner

If a layout itself has a layout, page.layout should still return the requested layout

Scenario

  • I have a blog with pages and posts
  • I have a layout called default.html with my header and footer
  • I have layouts called post.html and page.html which themselves specify layout: default
  • I want to know if the given thing I'm rendering is a page or a post, such as to add a class to the body tag via {{ page.layout }}

Expected

The post frontmatter says layout: post, I asked for layout: post, so when I query layout, return post

Actual

The last rendered layout is default, so page.layout will return default under all circomstances for both posts and pages

Screenshot

44791867

@penibelst

This behavior drives me crazy too. In @benbalter’s scenario it’s impossible to pass the original layout inside of post layout:

<body class="layout-{{ page.layout }}">
@parkr
Owner

Agreed, this should be fixed before 2.0. Thanks for filing the bug report, @benbalter!

@parkr
Owner

I can't reproduce this on HEAD. Can you?

@benbalter
Owner

Clarifying the scope and steps to reproduce. The problem is calls to {{ page.layout }} within the requested layout ("page") in the example above.

The exact scenario I suspect isn't all that uncommon. Page and post layouts, which inherit from default. Each then adding a body class, or similar, or including a header or footer, which does the same.

Given the use case above, I can't imagine wanting {{ page.layout }} to return "default" (the layout's layout... it should always return the user-requested layout.

@parkr parkr modified the milestone: 2.1, 2.0
@parkr parkr modified the milestone: 2.2, 2.1
@parkr
Owner

Didn't fix this before 2.0. We have a new top-level variable called layout, though, so you could do layout.layout if layout is not nil.

@alvarezp

What version has the "layout.layout" alternative been introduced? Here, using Jekyll 2.3.0, querying layout.layout from _layouts/default.html gives nothing and page.layout gives "default". There is no way to get the originally requested layout.

@alvarezp

This is what I want to do: have a default.html that, among other things, has this:

<link rel="stylesheet" href="/css/{{ page.layout }}.css">

@zackcote

If I'm to understand this issue, calling {{ page.layout }} anywhere should call the most immediate layout. This still isn't the case. If all of your layouts are derived from one base layout, calling {{ page.layout }} anywhere outputs the base layout. This is not the expected behavior.

@alvarezp

Hi. Any news on this issue?

@nternetinspired

Still broken in 3.0.0. :(

I'm faking the expected behaviour with:

<body class="{% if page.layout-class %}{{ page.layout-class }}-layout{% endif %}">
@parkr
Owner

I'm fairly confident it's never been any other way. I'm worried this will break gobs of sites.

@paulrobertlloyd

Surely layout.layoutwouldn’t break sites… if that is indeed a thing, as mentioned earlier. I could simplify my templates a lot if I had a way of detecting the immediate layout type.

@nternetinspired

…I could simplify my templates a lot if I had a way of detecting the immediate layout type.

:100:

@alvarezp

#2638 is referenced and has a patch. Has anybody tested it or has any comments?

@alvarezp

It should break sites. The natural thing is to do page.layout because it matches the rest of the behavior, where all page.* variables are taken from the original source.

Because this would imply breakage, it should be set for the next major release, not minor releases.

Also, as of right now, page.layout is useless anyway in inherited layouts. It doesn't even make sense for somebody to use it because it breaks expected behavior and what is actually returned is not helpful.

As a helper, in the following minor versions, a warning could be added during the build process to deprecate the current behavior of page.layout.

In non-inherited layouts it wouldn't break anything.

@kleinfreund

This should have the 3.0 label. Also, as @alvarezp staed, since page.layout currently is pretty pointless, breaking things won't be that big of a deal, no? I still need to think about an example where one would use page.layout with the current behavior.

@ramsey

I just ran into this myself. :+1:

@parkr
Owner

Can someone submit a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.