@Adrian I just tested buildDrafts: true in config.toml, then I set draft: true in sample-content-one.md in a starter kit Iām putting together, and then created a quasi json index with .Site.Pages in a separate template (layouts/section/json.html). Everything rendered in the expected manner.
As far as the page not being rendered with itās full content, the solution from @gdquest is a good one based on content typing (I think?). I agree with @spf13 that an extra flag would make this more complicated than necessary. If you are looking for something similar to your request for the generatePage flag youāve mentioned, something akin to the following may work for your use case:
<!--content/posts/my-content-sample.md-->
---
title: My Sample Content File
date: 2016-02-11
author: Ryan Watters
generatePage: false
---
Then in your single template:
<!--layouts/posts/single.html-->
{{ if .Params.generatePage "!=" "false"}}
{{ partial "my-header-partial.html"}}
<h1>{{ .Title }}</h1>
{{.Content}}
<!--yada,yada,yada....-->
{{ partial "my-footer-partial.html" }}
{{ end }}
This would create a blank page but still make the content data available to you in .Site.Pages. That said, itās just a blank page and would still create mysite.com/posts/my-content-sample/index.html. With my example, youād also have the issue of your <head> still rendering in the blank index.html, but thatās more a matter of the way youāre structuring your partials.
Then in your list page (eg, if you want to include something as post data but donāt want the page to come up in a list for whatever reason [unlikely use case, but you get the picture]):
<!--layouts/section/posts.html-->
{{ partial "my-header-partial.html"}}
<h1>{{.Title}}</h1>
<ul>
{{ range where .Data.Pages "generatePage" "!=" "false" }}
<li>{{.Title}}</li>
{{ end }}
</ul>
{{ partial "my-footer-partial.html" }}
Keep in mind that you can also use data and data-driven content just about anywhere in any template. You can reference individual data files housed in your /data folder or external resources (eg, via a json file hosted elsewhere). As @gdquest also mentioned, you can create your landing pages as static html files too if you want to deviate from the otherwise hierarchical model of home > list > content.
I know that @gdquest mentioned use of RED as a way to remove the empty index.html files/directories after build, but there may be a way to do this as part of a bash script in, for example, a wercker.yaml if you are interested in using Wercker to automate your build and deploy. I recently got the hang of it thanks to help from @ArjenSchwarz, so let me know if I can lend a hand.
@spf13 The more time I spend on these forums (and reading the documentation), the more I realize there are workarounds for just about every use case. I guess the question for many, but not all, of these workarounds is:
A. Keep the templating syntax barebones and let the community provide complex workarounds for different use cases (this works, but itās intimidating to newcomers or people who want to use Hugo in a professional context).
B. Bolster the functions, filters, etc of the templating layer.*
* I donāt know how much B would slow things down. If a lot, there is the tradeoff of readability-of-code-versus-slow-build-times. Iāve stewed a lot on this. Iāll start another topic on my thoughts for V1 or possibly just pm you.
