My html files have logic to not render files with param, (say) “skip=true” in the .md file but those files are still present in the public folder on build.
Is there a way to not build those files altogether in public folder?
I know that hugo has ignoreFiles variable in configuration that ignores files from rendering and are not included in build, but that’s based on regex for filename. Is there a way to do the same for all files with some param set to true?
Thanks @budparr.
Adding headless to a file will make that file not rendered in any builds, the use case I’m looking for is to have the flexibility to allow files with param “xyz = true” to be skipped or not, while building.
I don’t think there is any way to achieve this whitout having to add a where clause to every .Data.Pages or other collection called in your templates.
This may be tricky.
Yeah, I found some more documentation and it wouldn’t have worked anyway. Maybe you can tell us more about what you’re trying to accomplish in the end.
Put another way: “I have a set of filters that should restrict page generation to a subset of page categories.” For example, 3 builds: free users should be able to see the free-feature docs, basic users should be able to see the free and basic-feature docs, and full users should be able to see everything.
Our workaround for now is a modified template (to filter the menus) combined with a filter script written in bash. It works, but doesn’t feel quite nearly as clean as support built into the CLI. I could see the CLI help looking like this:
Flags:
...
-T, --buildTags single item or list; only generate content
where each page has a corresponding param
value of true
-D, --buildDrafts include content marked as draft
...
For comparison, Ansible has a nice CLI option that does something similar, of only processing a subset of content:
-t TAGS, --tags=TAGS only run plays and tasks tagged with these values
I think it would be interesting to have this kind of magnitude. I had a comparable use case on a project where editors wanted pages to be visbible only after several “approvals” Params had been set to true by different parties involve.
Fact-checking = true
Proofreading = true
Etc…
This to avoid having the editor sort out what Params had been set to true before undrafting the piece.
I wonder if this is something complicated to implement.
Netlify CMS has built in this sort of functionality as an option:
The publish_mode option allows you to enable “Editorial Workflow” mode for more control over the content publishing phases.
From a technical perspective, the workflow translates editor UI actions into common Git commands:
Save draft: Commits to a new branch (named according to the pattern cms/collectionName-entrySlug), and opens a pull request
Edit draft: Pushes another commit to the draft branch/pull request
Approve and publish draft: Merges pull request and deletes branch