Skip to content


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

shmuel opened this Issue · 28 comments

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:

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.


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


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.


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.


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


+1 for haml layouts


+1 for haml layouts

jg commented

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


+1 for haml layouts


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


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.


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


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


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.


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


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


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

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

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).

Jekyll member

Agreed. I emailed Tom.


Yep, put it in a 1.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.


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

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

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.


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.

Jekyll member

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

@parkr parkr closed this

@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 })

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