I have a non-standard scenario that I’m trying to code for, and liquid isn’t rendering in the way I want it to. I’m generating out a jekyll site to meet kindle ebook specifications, and the specs require each chapter to contain a list of subpages aggregated in the same page.
So “Chapter 1” might consist of topic_a.md, topic_b.md, and topic_c.md. The kindle spec requires the format to look like this:
- chapter1.html#topic_a
- chapter1.html#topic_b
- chapter1.html#topic_c
In other words, there’s a base page (chapter1.html) that contains various sub-pages (with distinct anchors, such as #topic_a) in one long page.
Here’s how I thought to approach this. I have a collection called “docs.” For all pages that are contained in chapter 1, I have this frontmatter:
section: chapter1
Then I use a for loop to get all those pages and stuff them into a chapter1.html page:
{% assign doclist = site.docs | sort: 'weight' %}
{% for page in doclist %}
{% if page.section == "chapter1" %}
<h1>{{page.title}}</h1>
{{page.content}}
{% endif %}
{% endfor %}
However, when I do this, any liquid on the page doesn’t consistently render. I am not sure why. I know liquid is supposed to render before Markdown, but in this case, it doesn’t seem to be behaving that way. Or the liquid renders first, but in the wrong order. I want the page’s liquid to render before the liquid on this base page.
If this is a hard limitation with Jekyll, what are my alternatives?
Option 1: Don’t use liquid in pages – just use Markdown. I could probably get by with this approach, but there are quite a few areas where I filter out content (such as youtube videos) that are incompatible with kindle. (I want to single source this content into both a kindle ebook and a regular website, so I can’t just remove these video embeds.)
Option 2: Store all content in includes. Then I would have a bunch of files that merely served as shells that had pointers to include chunks of content. The page frontmatter would be separated from the page content. This might make things more confusing from an authoring perspective.
Option 3: Combine my individual pages into long pages. Unfortunately this would make authoring really cumbersome and I could no longer repurpose the content for the web.
Those are the only options I can think of right now. I think I’ve run into this issue previously, a couple of years ago when I was rendering an entire site into one long page to convert to PDF.