piranha/gostatic

Inner template as a template func

holic opened this issue · 1 comments

holic commented

Continuing from #34 (comment)

In pagination, I'm using the .Raw content to extract an "excerpt" from each post:

{{ define "excerpt" }}

{{ $more := "\n<!-- more -->\n" }}
{{ $excerpt_open := "<!-- excerpt -->\n" }}
{{ $excerpt_close := "\n<!-- /excerpt -->" }}

{{ if contains $more .Raw }}
    {{ .Raw | cut "" $more | markdown }}
{{ else if contains $excerpt_open .Raw }}
    {{ .Raw | cut $excerpt_open $excerpt_close | markdown }}
{{ else }}
    {{ .Raw | cut "" "\n\n" | markdown }}
{{ end }}

{{ end }}

However, in some cases, the .Raw may contain a template include (e.g. {{ template "youtube" "someid" }} for easier YouTube embeds). Because I'm pulling this from the .Raw content, the template tag is never parsed, so the rendered excerpt on the pagination pages uses the literal {{ template ...}} syntax rather than having it rendered (like inner-template).

I tried adding an inner-template step after the template that creates the excerpt:

pages/*.page: */*/*.md
    rename ../page-*
    ext .html
    directorify
    template archive
    inner-template
    template page

However, the markdown filter/template func in the excerpt template above escapes the " and results in the template string looking like {{ template &quot;youtube&quot; ...}} which results in the following error:

template: ad-hoc:156: unexpected "&" in template invocation

There's two ways I can see this getting fixed.

  1. Move some of the logic of ProcessInnerTemplate into a template function so it can be called like `{{ .Raw | cut "" "\n\n" | render | markdown }} so that the inner template is rendered before processing as Markdown (and ultimately escaping quotes and other HTML entities).

  2. Overwrite page.raw after making a call to the inner-template step in the config, so that ProcessInnerTemplate ends with:

    page.SetContent(buffer.String())
    page.raw = page.Content()
    

The second option does work, but it feels a bit dirty/hacky because we don't know when/where inner-template might be used in the build step. So it might be better to implement it as a template function as described in the first option.

Thoughts?

I'd say extracting inner-template is not anything special unlike (I decided in previous discussion, ha-ha) config is, so it would make sense to have it as a function (like markdown).