Plugins are evaluated AFTER layouts meaning plugins can't effect layouts. #225

Closed
shmuel opened this Issue Oct 31, 2010 · 28 comments

Comments

Projects
None yet
@shmuel

shmuel commented Oct 31, 2010

From what I can tell plugins are being evaluated after layouts so they effect pages but not layouts. You can see an example of what I mean by installing this plugin:

http://blog.martiandesigns.com/2010/07/19/haml-sass-converters-for-jekyll.html

Once installed try putting some HAML in both a layout and page. The HAML used in a page will be evaluated correctly and the HAML in the layout will be spit out literally.

@imathis

This comment has been minimized.

Show comment
Hide comment
@imathis

imathis Oct 31, 2010

Contributor

Haml layouts would be fantastic. Having this would let me finally stop using Henrik's stale fork.

Contributor

imathis commented Oct 31, 2010

Haml layouts would be fantastic. Having this would let me finally stop using Henrik's stale fork.

@imanel

This comment has been minimized.

Show comment
Hide comment
@imanel

imanel Nov 5, 2010

It looks like only page content is transformed using converter and layout isn't. Please look into convertible.rb, method "do_layout". After first Liquid parse there is "transform" method called which render view using converter. After second Liquid parse(in layout loop) there is no such call so nothing is converted. I think that we just need to add second 'transform' call preceded by change of converter(layout can have different converter that page)
I don't have time to test that so if someone will have opportunity it will be great.

imanel commented Nov 5, 2010

It looks like only page content is transformed using converter and layout isn't. Please look into convertible.rb, method "do_layout". After first Liquid parse there is "transform" method called which render view using converter. After second Liquid parse(in layout loop) there is no such call so nothing is converted. I think that we just need to add second 'transform' call preceded by change of converter(layout can have different converter that page)
I don't have time to test that so if someone will have opportunity it will be great.

@kuukii

This comment has been minimized.

Show comment
Hide comment
@kuukii

kuukii Nov 7, 2010

Adding layout.content = converter.convert(layout.content) right at the beginning of the while layout block did the trick for me.
An official fix would be nice though.

kuukii commented Nov 7, 2010

Adding layout.content = converter.convert(layout.content) right at the beginning of the while layout block did the trick for me.
An official fix would be nice though.

@winton

This comment has been minimized.

Show comment
Hide comment
@winton

winton Feb 28, 2011

+1 for this fix. Pretty annoying that you can't use converter plugins on layouts.

winton commented Feb 28, 2011

+1 for this fix. Pretty annoying that you can't use converter plugins on layouts.

@rubiii

This comment has been minimized.

Show comment
Hide comment
@rubiii

rubiii Apr 2, 2011

+1 for haml layouts

rubiii commented Apr 2, 2011

+1 for haml layouts

@georges

This comment has been minimized.

Show comment
Hide comment
@georges

georges Apr 12, 2011

+1 for haml layouts

georges commented Apr 12, 2011

+1 for haml layouts

@jg

This comment has been minimized.

Show comment
Hide comment
@jg

jg Apr 17, 2011

+1, commit with jekyll fix at (jg/jekyll@cee30aa)

jg commented Apr 17, 2011

+1, commit with jekyll fix at (jg/jekyll@cee30aa)

@mferrier

This comment has been minimized.

Show comment
Hide comment
@mferrier

mferrier Apr 21, 2011

@dataink

This comment has been minimized.

Show comment
Hide comment
@dataink

dataink May 12, 2011

+1 for haml layouts

dataink commented May 12, 2011

+1 for haml layouts

@postmodern

This comment has been minimized.

Show comment
Hide comment
@postmodern

postmodern May 12, 2011

Contributor

This may have been answered before, but why does Jekyll not use the tilt gem, which supports almost every template system and markup imaginable?

Contributor

postmodern commented May 12, 2011

This may have been answered before, but why does Jekyll not use the tilt gem, which supports almost every template system and markup imaginable?

@tomash

This comment has been minimized.

Show comment
Hide comment
@tomash

tomash May 13, 2011

Contributor

because haml and erb are unsafe (as opposed to markdown & textile) because they can evaulate any arbitrary ruby code. which is not fun for github as it's used for generating github pages.

Contributor

tomash commented May 13, 2011

because haml and erb are unsafe (as opposed to markdown & textile) because they can evaulate any arbitrary ruby code. which is not fun for github as it's used for generating github pages.

@winton

This comment has been minimized.

Show comment
Hide comment
@winton

winton May 13, 2011

Github needs to fork Jekyll instead of limiting the growth of the project.

winton commented May 13, 2011

Github needs to fork Jekyll instead of limiting the growth of the project.

@tomash

This comment has been minimized.

Show comment
Hide comment
@tomash

tomash May 15, 2011

Contributor

...are you really implying Jekyll isn't a project of @mojombo, founder of Github?

Contributor

tomash commented May 15, 2011

...are you really implying Jekyll isn't a project of @mojombo, founder of Github?

@winton

This comment has been minimized.

Show comment
Hide comment
@winton

winton May 15, 2011

No, I'm implying that @mojombo is limiting the growth of the project by rejecting patches that don't fit with Github's very unique use-case.

winton commented May 15, 2011

No, I'm implying that @mojombo is limiting the growth of the project by rejecting patches that don't fit with Github's very unique use-case.

@anbotero

This comment has been minimized.

Show comment
Hide comment
@anbotero

anbotero Jun 12, 2011

Oh, so it's because of execution of Ruby code... what a shame. Oh, well, sorry Slim: back to Markdown it is.

Oh, so it's because of execution of Ruby code... what a shame. Oh, well, sorry Slim: back to Markdown it is.

@Kwpolska

This comment has been minimized.

Show comment
Hide comment
@Kwpolska

Kwpolska Jun 12, 2011

I'd rather propose an übersafe mode, which will disable stuff like that.

I'd rather propose an übersafe mode, which will disable stuff like that.

@postmodern

This comment has been minimized.

Show comment
Hide comment
@postmodern

postmodern Jun 13, 2011

Contributor

Ubersafe should be the default mode. There could be options to enable unsafe templating languages. This could easily be implemented with Tilt.

Contributor

postmodern commented Jun 13, 2011

Ubersafe should be the default mode. There could be options to enable unsafe templating languages. This could easily be implemented with Tilt.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Apr 15, 2013

Member

@mojombo & @mattr-: What do you think of this and #268? I think this requires too much thought to be considered for 1.0

Member

parkr commented Apr 15, 2013

@mojombo & @mattr-: What do you think of this and #268? I think this requires too much thought to be considered for 1.0

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Apr 15, 2013

Member

If this and #268 are the only large issues holding up 1.0, I think we can punt. (I'm definitely in favor of smaller more frequent releases).

Member

mattr- commented Apr 15, 2013

If this and #268 are the only large issues holding up 1.0, I think we can punt. (I'm definitely in favor of smaller more frequent releases).

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Apr 15, 2013

Member

Agreed. I emailed Tom.

Member

parkr commented Apr 15, 2013

Agreed. I emailed Tom.

@mojombo

This comment has been minimized.

Show comment
Hide comment
@mojombo

mojombo Apr 15, 2013

Contributor

Yep, put it in a 1.1.

Contributor

mojombo commented Apr 15, 2013

Yep, put it in a 1.1.

@jpap

This comment has been minimized.

Show comment
Hide comment
@jpap

jpap Jun 9, 2013

+1

I just encountered this issue after writing a Jade plugin. Works great for pages, not layouts.

Would love to be able to write my layouts in Jade, rather than compile them externally.

jpap commented Jun 9, 2013

+1

I just encountered this issue after writing a Jade plugin. Works great for pages, not layouts.

Would love to be able to write my layouts in Jade, rather than compile them externally.

@catsby

This comment has been minimized.

Show comment
Hide comment
@catsby

catsby Jan 16, 2014

Contributor

Was this issue ever merged/resolved? Notes above mention 1.1 and Jekyll is at 1.4 now

Contributor

catsby commented Jan 16, 2014

Was this issue ever merged/resolved? Notes above mention 1.1 and Jekyll is at 1.4 now

@troyswanson

This comment has been minimized.

Show comment
Hide comment
@troyswanson

troyswanson Apr 24, 2014

Member

@catsby I get the feeling that this will be tackled in 3.0 with the complete revamp of the plugin system. Plugins for all the things!

Ref: #1414 & #1272

Member

troyswanson commented Apr 24, 2014

@catsby I get the feeling that this will be tackled in 3.0 with the complete revamp of the plugin system. Plugins for all the things!

Ref: #1414 & #1272

@parkr parkr modified the milestones: 3.0, 2.0 Apr 24, 2014

@robwierzbowski

This comment has been minimized.

Show comment
Hide comment
@robwierzbowski

robwierzbowski May 11, 2014

Contributor

In the interim, if you're using a Grunt / Gulp / Yeoman build system, you can compile your html preprocessor files first, then run the Jekyll plugin. Trying that out now on my site.

Contributor

robwierzbowski commented May 11, 2014

In the interim, if you're using a Grunt / Gulp / Yeoman build system, you can compile your html preprocessor files first, then run the Jekyll plugin. Trying that out now on my site.

@stevenleeg

This comment has been minimized.

Show comment
Hide comment
@stevenleeg

stevenleeg May 28, 2014

I was looking for this ability yesterday when trying to compile external CSS into inline html styles (gasp) for email templates.

Having the ability to alter layouts with a plugin would be awesome for this use case and save me a ton of time.

I was looking for this ability yesterday when trying to compile external CSS into inline html styles (gasp) for email templates.

Having the ability to alter layouts with a plugin would be awesome for this use case and save me a ton of time.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Jul 31, 2014

Member

We'll solve this in Jekyll 3.0 with a new Hooks-based plugin system. Hurrah!

Member

parkr commented Jul 31, 2014

We'll solve this in Jekyll 3.0 with a new Hooks-based plugin system. Hurrah!

@parkr parkr closed this Jul 31, 2014

@dgmstuart

This comment has been minimized.

Show comment
Hide comment
@dgmstuart

dgmstuart Feb 2, 2016

@parkr hooks sound like a great approach. But how should they actually be used this scenario? The best I can come up with is:

Jekyll::Hooks.register :site, :pre_render do |site|
  site.layouts = site.layouts.inject({}) do |hash, (name, layout)|
    layout.content = layout.transform
    hash.merge({ name => layout })
  end
end

...which works, but seems pretty hacky: mapping over the layouts, reaching inside each one and transforming the content. Is there a more direct way to target the specific layout being used?

@parkr hooks sound like a great approach. But how should they actually be used this scenario? The best I can come up with is:

Jekyll::Hooks.register :site, :pre_render do |site|
  site.layouts = site.layouts.inject({}) do |hash, (name, layout)|
    layout.content = layout.transform
    hash.merge({ name => layout })
  end
end

...which works, but seems pretty hacky: mapping over the layouts, reaching inside each one and transforming the content. Is there a more direct way to target the specific layout being used?

@jekyllbot jekyllbot locked and limited conversation to collaborators Feb 27, 2017

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