Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


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

benbalter opened this Issue · 18 comments

9 participants


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


  • 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 }}


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


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




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 }}">

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


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


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

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.


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.


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">


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.


Hi. Any news on this issue?


Still broken in 3.0.0. :(

I'm faking the expected behaviour with:

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

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


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.


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



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


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.


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.


I just ran into this myself. :+1:


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.