Skip to content

Loading…

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

Closed
shmuel opened this Issue · 28 comments
@shmuel

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

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

@imanel

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

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

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

@rubiii

+1 for haml layouts

@georges

+1 for haml layouts

@jg
jg commented

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

@dataink

+1 for haml layouts

@postmodern

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

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

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

@tomash

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

@winton

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

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

@Kwpolska

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

@postmodern

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

@parkr
Jekyll member

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

@mattr-
Jekyll 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).

@parkr
Jekyll member

Agreed. I emailed Tom.

@mojombo

Yep, put it in a 1.1.

@jpap

+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

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

@troyswanson
Jekyll 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

@parkr parkr modified the milestone: 3.0, 2.0
@robwierzbowski

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

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
Jekyll member

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

@parkr parkr closed this
@dgmstuart

@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?

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.