Can Liquid includes generate different output in different contexts?

[robweychert]

This question might be more broadly about Liquid than Eleventy’s specific implementation of it, but:

My site’s posts have a lot of figures that incorporate inline SVG, which works great on the main site, but I want to replace the SVG with PNG when those posts are published in my RSS feed and newsletter. I thought it would be a simple matter of a conditional in the figure include, something like this:

{% if layout == 'layouts/rss.liquid' or layout == 'layouts/newsletter.liquid' %}
  {{ PNG content here }}
{% else %}
  {{ SVG content here }}
{% endif %}

But in all contexts, it assumes the layout in question is the one specified in the post’s front matter.

I also tried setting variables in each layout like this:

{% assign offsite = true %}

And then tried this in the figure include:

{% if offsite %}
  {{ PNG content here }}
{% else %}
  {{ SVG content here }}
{% endif %}

But I guess includes can’t read variables in template files?

Anyway, I’m out of ideas for the moment. Suggestions would be much appreciated!

[pdehaan]

Yeah, I think I've found {% assign %} will put the variable in the current page's scope, but not in layouts or other files. But setting things in front matter will propagate or data directory files or probably even eleventyComputed will work.

Not sure if you have a repo w/ a simple test case where I can take a look at your use case.

[pdehaan]

Nice! I did actually work on a transform version of the Cheerio idea last night and almost replied. But then waited until I could find a sample RSS file to test on, and found out it didn't really work since the random, sample RSS file I found used <![CDATA[ ... ]]> and apparently cheerio wasn't finding those <figure> elements anymore once they're nested in CDATA. Which then would bring me back to my original idea of needing to:

1. convert from RSS to JSON,
2. loop over each <item> tag in the feed,
3. convert each figure > svg to figure > img in each item's <description> and <content:encoded> tags,
4. convert from JSON back to RSS.

[robweychert]

Ah, yep, I’ve never managed to make an RSS feed without incorporating CDATA. Glad I didn’t have to go the RSS to JSON to RSS route.

[pdehaan]

Yeah, it's a definite tradeoff.
RSS => JSON => RSS can be "safer", but definitely a lot more hoops to jump through.
RegExp can be super nice in some cases but difficult to manage and fragile. For example, if you have a <span data-attr="true"> in your code, it might not be detected by your RegExps, but the closing tag would still be removed. Similarly, what if there were SOME <span> tags you wanted to keep, but certain ones within a <figure> that you wanted to remove. It gets hard to restrict the logic. But it all eventually comes down to exact use cases and what this particular RSS feed looks like.

[robweychert]

The markup patterns on this site are pretty predictable, so I feel confident about the regex solution, but I hear you on the edge cases!

[robweychert]

Although now that you mention it, in the list of strings to remove, I think I’ll make it just a little bit safer by changing that '<span>' to /\<span.*?\>/g.