These checks look for the rightmost location of specific directory names (content, static, etc), requiring the actual source repository have directories named that, despite the fact that the files are copied to a secondary location.
In addition, the implementation of that check requires that the directory (e.g. content) must have a slash preceding the prescribed name, so you cannot have them at the very top of the workspace.
https://github.com/deadmoose/hugo_rules_content_demo demonstrates some potential layouts:
- top_level shows the
content directory at the very top & fails: failed to get relative path: couldn't find content in content/_index.md
- anything_else doesn't call it
content, and thus fails: failed to get relative path: couldn't find content in foo/bar/_index.md
- down_one works because the content directory is
foo/content so it's internally calling relative_path('foo/content/_index.md', 'content')
- double_content shows a situation where someone happens to name a directory within their site
content. Since the rightmost occurrence of /content/ is treated as special, both foo/content/_index.md and foo/content/foo/content/_index.md try to generate the same output file & it chokes.
I've got full sympathies for how painful it is to do complex transforms from your source layout to something else, but the silent misbehavior if anyone happens to use one of the fairly common reserved words (content, static, images, layouts, data, assets, i18n) is pretty dangerous, and failing on a workspace-root version of one of those is extremely confusing when onboarding.
These checks look for the rightmost location of specific directory names (
content,static, etc), requiring the actual source repository have directories named that, despite the fact that the files are copied to a secondary location.In addition, the implementation of that check requires that the directory (e.g.
content) must have a slash preceding the prescribed name, so you cannot have them at the very top of the workspace.https://github.com/deadmoose/hugo_rules_content_demo demonstrates some potential layouts:
contentdirectory at the very top & fails:failed to get relative path: couldn't find content in content/_index.mdcontent, and thus fails:failed to get relative path: couldn't find content in foo/bar/_index.mdfoo/contentso it's internally callingrelative_path('foo/content/_index.md', 'content')content. Since the rightmost occurrence of/content/is treated as special, bothfoo/content/_index.mdandfoo/content/foo/content/_index.mdtry to generate the same output file & it chokes.I've got full sympathies for how painful it is to do complex transforms from your source layout to something else, but the silent misbehavior if anyone happens to use one of the fairly common reserved words (
content,static,images,layouts,data,assets,i18n) is pretty dangerous, and failing on a workspace-root version of one of those is extremely confusing when onboarding.