@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.
