Add some pre- and post-rendering hooks #1771

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
6 participants
Owner

parkr commented Dec 4, 2013

This is a monkey-patch approach, but it's up for debate. Thoughts?

Plugins would implement the hooks by overwriting these empty methods.

The other approach is something like
Jekyll::Filters.add_post_filter(SomeClass) and that class would have the one
method required by the method and it would be called in level of priority.

/cc @imathis @benbalter @mattr-

Contributor

imathis commented Dec 4, 2013

👍

There some good use cases for this. For one, I use something like this in Octopress to add support for Redcarpet-style fenced code blocks regardless of template language. The only way I can do it is to parse pages before Liquid and other processors have their way.

Contributor

benbalter commented Dec 4, 2013

Plugins would implement the hooks by overwriting these empty methods... The other approach is something like Jekyll::Filters.add_post_filter(SomeClass)

If we take the monkey-patch route, what happens if two plugins want to attach to the same hook?

Sounds very much like Drupal-style plugin hooks versus WordPress-style plugin hooks. One thing WordPress does well is allows developers to specify a priority (10 being the default, etc.) so that plugins can better plan their interaction with internals and other plugins.

parkr referenced this pull request Dec 6, 2013

Closed

Plugin Ecosystem #1272

Member

penibelst commented Dec 6, 2013

I have similar use case like @imathis.

In my Russian and German posts I set a lot of soft hyphens and no-break spaces manually. As I prefer markdown for prose, I found that using

  • · for  
  • ~ for ­
  • «» for <q></q> in Russian
  • »« for <q></q> in German
  • ¸2 for <sub>2</sub>

let my source code readable. Now I use a simple liquid replace filter over the whole {{ content }} to convert my own character set to HTML tag and entities. It works nice until my markdown engine of choice starts to use the same special characters for something else. If it actually happens, a pre-rendering hook would allow me to write a more durable syntax extension.

@penibelst penibelst commented on the diff Dec 7, 2013

lib/jekyll/convertible.rb
@@ -147,10 +147,13 @@ def do_layout(payload, layouts)
payload["pygments_prefix"] = converter.pygments_prefix
payload["pygments_suffix"] = converter.pygments_suffix
- self.content = self.render_liquid(self.content,
- payload,
- info)
+ self.pre_render
+ self.content = self.render_liquid(self.content, payload, info)
+ self.post_render
+
+ self.pre_transform
@penibelst

penibelst Dec 7, 2013

Member

Why do you need post_render and pre_transform? One procedure is enough.

Member

penibelst commented Dec 7, 2013

After realizing that Liquid is performed before Markdown (right?), I think a custom liquid filter is a better solution for my use case mojombo#1771 (comment).

Member

gjtorikian commented Jan 3, 2014

Sounds very much like Drupal-style plugin hooks versus WordPress-style plugin hooks. One thing WordPress does well is allows developers to specify a priority (10 being the default, etc.) so that plugins can better plan their interaction with internals and other plugins.

I may be totally wrong in understanding this point, but what if priority is determined based on order in the _config.yml file?

parkr closed this Jan 25, 2014

parkr deleted the pre-and-post-filters branch Jul 26, 2014

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.