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

Closed
benbalter opened this Issue Jan 12, 2014 · 22 comments

Comments

Projects
None yet
Contributor

benbalter commented Jan 12, 2014

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

Member

penibelst commented Jan 12, 2014

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

parkr commented Jan 12, 2014

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

Owner

parkr commented Jan 13, 2014

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

Contributor

benbalter commented Jan 13, 2014

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 May 5, 2014

@parkr parkr modified the milestone: 2.2, 2.1 Jun 16, 2014

Owner

parkr commented Jul 31, 2014

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?

Contributor

nternetinspired commented Feb 4, 2015

Still broken in 3.0.0. :(

I'm faking the expected behaviour with:

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

parkr commented Feb 4, 2015

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

Contributor

paulrobertlloyd commented Feb 4, 2015

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.

Contributor

nternetinspired commented Feb 4, 2015

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

💯

alvarezp commented Feb 4, 2015

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

alvarezp commented Mar 6, 2015

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.

Contributor

kleinfreund commented Mar 20, 2015

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 commented May 16, 2015

I just ran into this myself. 👍

Owner

parkr commented May 18, 2015

Can someone submit a PR?

@envygeeks envygeeks modified the milestone: 3.1, 2.2 Aug 26, 2015

@envygeeks envygeeks modified the milestone: 3.0, 3.1 Aug 26, 2015

Contributor

envygeeks commented Aug 26, 2015

Does anyone know how hard it is to even determine this?

@envygeeks envygeeks modified the milestone: 3.0.1, 3.0 Oct 29, 2015

envygeeks locked and limited conversation to collaborators Feb 25, 2016

Contributor

jekyllbot commented Jun 6, 2016

This issue has been automatically marked as stale because it has not been commented on for at least
three months.

The resources of the Jekyll team are limited, and so we are asking for your help.

If you can still reproduce this error on the 3.1-stable or master branch,
please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, please consider building it first as a plugin. Jekyll 3 introduced
hooks which provide convenient access points throughout
the Jekyll build pipeline whereby most needs can be fulfilled. If this is something that cannot be
built as a plugin, then please provide more information about why in order to keep this issue open.

Thank you for all your contributions.

jekyllbot added the stale label Jun 6, 2016

jekyllbot closed this Jul 6, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.