`Users` always returned as the Section in directory-based archetypes

When I use the directory-based archetype functionality and my template contains {{ .Section }}, the returned value is Users instead of the actual section title. If the archetype template is a regular “top-level” archetype, then {{ .Section }} renders as expected. Is this expected behavior or a bug?

It occurs to me that Users is probably coming from the fact that I’m on a Mac and that Users is the root of the users directory. So I’m guessing that the issue is in the code that sets .Section by parsing the path of the file being created. Perhaps it is not configured for nested sections.

My workaround:

{{- $section := replaceRE "/.*content/([^/]+).*" "$1" .File.Dir -}}

Not sure how that will work on platforms that use different path dividers.

For the next time please post the whole template/layout file where this happens. Looks to me like a misunderstood dot (./context).

1 Like

When I get things into shape for a Git upload, I will, but the question is really simple. In the index.md template for a directory-based archetype, what should {{ .Section }} render?

It is NOT simple. If that .Section is within a range or with command it’s something else than it is outside.

I appreciate your help @davidsneighbour, but in this case, it IS that simple. :slight_smile: Just a plain {{ .Section }} call. No other content or code. In other words, if the only contents of an index.md template used in directory-based archetype is {{ .Section }}, what should it return?

Similarly, the ArchetypeFileData struct contains source.File which exposes Dir. The comments on Dir indicate that it should be relative to the content root, but when I call {{ .Dir }} in an otherwise empty template in a directory-based archetype, I get the full canonical path to the file. So I suspect that there is an issue with populating that field when the struct is initialized in this case. The exact same template code works as expected in a “regular” archetype.

Anyways, I do appreciate you taking the time to reply. If anyone else runs into this issue, a regex based workaround is posted above.



1 Like