Ignore .md files in build with particular param set


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?

Any help is appreciated.

1 Like

I think draft = true will help.

I would like to keep the other files for a separate build and so adding “draft = true” is not desirable.

Not in the docs, but see if headless helps you: http://gohugo.io/news/0.35-relnotes/

1 Like

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.

What I want to accomplish is to create 2 sets of builds:

  1. A build which has all the files which have param “xyz = true”, “xyz = false” and no “xyz” param at all (i.e. nil).
  2. A build which has only the files with “xyz = true”

So if they’re completely separate builds will you --buildDrafts on one of them get you there?

I have drafts which I don’t want to be included. Also if I want a combination of params as acceptance criteria, I can’t do that with --buildDrafts.

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:

  -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
1 Like

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

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.

Use the ignoreFiles setting

1 Like

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