Add some pre- and post-rendering hooks #1990

Closed
wants to merge 1 commit into
from

Projects

None yet

5 participants

@parkr
Member
parkr commented Jan 25, 2014

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 @benbalter @mattr-

@parkr
Member
parkr commented Jan 25, 2014

This replaces #1771, which was pointed at mojombo:master, rather than jekyll:master.

@gjtorikian
Member

This replaces #1771, which was pointed at mojombo:master, rather than jekyll:master.

Wait, what? Can you elaborate? If you move a repo into a separate org, do all the PRs become null and void?

@parkr
Member
parkr commented Jan 26, 2014

Wait, what? Can you elaborate? If you move a repo into a separate org, do all the PRs become null and void?

Yes! The pull request seems to store the base and HEAD data and if the base changes, it needs to be closed and re-created.

@mattr-
Member
mattr- commented Jan 26, 2014

This isn't really a monkey patching type of approach is it? You'd just need to override the methods that you inherit from Convertible. I think I'm cool with this, but I'm having a hard time visualizing a scenario where the hooks would be useful. Is there an example that you could provide for my lagging brain?

@parkr
Member
parkr commented Jan 26, 2014

@mattr- Jekyll has a very strict rendering process, and some things (e.g. HTML Pipeline) need to be run before or after a particular piece of this render process. For example, if I wanted to write a plugin that linkified all (#\d+) statements in a Markdown file (like our sites/docs/history.md), they couldn't do it without monkey-patching some horribleness in Site#process or something. This gives a publicly accessible API through which plugin writers may run some code before and after certain pieces of the rendering process.

@benbalter
Contributor

@parkr, I'd vote for a mechanism that allows chaining multiple filters on the same content, not simply more granular control of where a single converter can run in the pipeline.

@mattr-, Two use cases that I've run into, FWIW, are if I want to add emoji or @mention support. Both should really be run after the markdown's been converted to HTML, such that emoji or @mentions in pre or code blocks can be properly ignored, or if I want to make a manual @mention like <a href="#">@foo</a>. Right now, I'd need to hack it in as a generator that modifies posts directly, and use extremely complex regex.

Another use case, for example borrowing from WordPress, is they have the post_content filter, which they dogfood internally. If I write wordpress in a post, regardless of what other processors run, I always get WordPress on the otherside. If I wanted to do that with github -> GitHub today, there's nothing in core designed to support that (which I'd imagine we'd want to encourage).

@parkr
Member
parkr commented Jan 26, 2014

@parkr, I'd vote for a mechanism that allows chaining multiple filters on the same content, not simply more granular control of where a single converter can run in the pipeline.

@benbalter For sure, I would love to move to multiple converters: find all the converters that match extension .x and run it through those converters in order of their priority.

@mattr-
Member
mattr- commented Jan 26, 2014

Thanks y'all for filling me in. 😄 ❤️

@parkr parkr closed this Mar 17, 2014
@parkr parkr reopened this Mar 17, 2014
@mattr-
Member
mattr- commented Jun 7, 2014

Oh, I'm 👍 on this by the way. 😃

@parkr
Member
parkr commented Jun 7, 2014

This is totally the wrong approach. We can keep this open to track but let's not actually ever merge this code as-is. 😄

@parkr parkr closed this Jul 26, 2014
@parkr parkr deleted the pre-and-post-filters branch Jul 26, 2014
@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.