Parsing shortcodes as liquid tags/includes

Help
1

I’m trying to let Jekyll interpret something like this:

<!--< include myInclude.liquid property = value >-->

as

{% include myInclude.liquid property = value %}

I’ve tried simple text replacement like this:

{{ content | replace: '<!--<', '{%' | replace: '>-->', '%}' }}

But either the curly trip up Jekyll because of a syntax error, or I escape the strings and they’re actually escaped and the liquid tags are never parsed as liquid.

Am I trying to do the impossible, or is there a some other way I haven’t thought about yet?

Background for why I even want this: I’m migrating our site from Forestry to Tina CMS, which is supposed to be Forestry V2. Many of our markdown files contain Jekyll includes. Tina messes these up, adding \ to escape curly braces and underscores. Now that’s obviously an issue that should be fixed in the Tina project, but for now I need a quick solution to circumvent it.

2

I think the issue with this approach is that Liquid is only evaluated in one pass (AFAIK), so the output of the text replacements won’t get evaluated a second time by Liquid (even if it is syntactically correct Liquid).

Possibly a custom Jekyll plugin could do the transform? But I’m not sure…

3

Okay thanks, now I know this approach won’t get me any further!

4

I gather the issue is that Tina CMS allows you to edit Markdown, but it doesn’t support Jekyll’s Markdown+Liquid format? So any Liquid code is escaped.

Another option might be to try and de-escape the Markdown before running jekyll build. For example, a shell/python/ruby/etc script could be run over the sites source code to reverse the escaping applied by Tina.

5

Mm yeah I hadn’t thought of that! It feels a bit brittle though. Anyway, I’m few steps further and found out that if I don’t have any underscores in the parameters, the only thing I need to do is removing a superfluous snippet name that’s inserted by Tina. IMO the issues are actually unintended and I hope they’ll be fixed soon.

6

If anyone else has this issue: you need to add a name field to the property’s match object. That name, which is different from the property’s name, can contain special characters. This behavior may change, so here’s the Github issue for reference.