First: I’m going to deprecate.Site.Sections – even if it is going to be painful. I have stepped lightly around that code for a while now, but I think now is the time to do something about it. Sections are taxonomies, which made sense when @spf13 created them (easy to implement), but now it is filled with restrictions.
To the questions. To fill the gap, I’m adding another method, thinking:
Without any argument it will behave like .Site.Sections (but return an ordered list type, i.e. not a map).
Will get the subsections below “blog” etc.
Note that to get a specific section (which is a Page), you do:
.Site.GetPage "section" "blog"
Does the name .GetSections sound OK? Note that .Sections is taken until we remove it …
And testing for the existence of a top-level section would be in .Site.GetSections "quotes" instead of .Site.Sections.quotes? Or would it have to be in (.Site.GetSections) "quotes"?; I’ve never quite figured out the rules about when arguments are gobbled up by the first function and you have to use parens to disambiguate.
On an added note, I think I’m going to do a “hard deprecation” of .Sections; making bot structures work side-by-side is too much work. I will let .Sections return an empty map and write a detailed ERROR log statement with upgrade instructions.
The idea is that a Page is a Page is a Page. Which can be a section.
The whole idea of this exercise, i.e. nested sections, is to create a proper tree that “kind of” matches what you see on disk. So at some point, to get some benefits from this, you must at least mentally, have a tree structure in mind when creating your templates.
So .Sections refer to the sections below the current page.
Your example isn’t even a proper section, but let us make it one:
(.Site.GetPage "section" "blog" "vacations").Parent.Parent => Home
My only question left (before I start thinking more), is: Should .Section return blog for all the pages in the sections above? This would typically be used in where clauses on the home page, so I’m tempted to say yes: You would like to get both vacations and Trump stuff without making it any harder. So .Section = the first folder, so to speak, like it is today.
Would it be possible–assuming that every dir with an _index.md is a section–to do the following? Very similar to yours but just one tweak at the end, plus some additional notation for my own knowledge:
.Site.Home.Sections => blog, trump, vacations (I’m noting your comment about it being simple once we get to use .Site.Sections)
$blogSection := .Site.GetPage "section" "blog" returns all associated with blog/_index.md, including all pages under both vacations and trump (i.e., $blogSection.Pages and $blogSection.RegularPages). So then as a consequence, a layout at layout/blog/list.html with range .Data.Pages would also include all pages under trump and vacations (i.e., 8 pages total).
I’d actually like @budparr 's thoughts on this since he’s the guru on creating relationships between content types:
If everything with an _index.md is a section, does it make more sense—or is it possible without breaking every Hugo site—to use .GetPage "section" "vacations" instead? Then you can check for .Parent using with, etc; e.g., breadcrumbs spring to mind here. This would mean that moving sections of content within source org could be done independently of the templating since .Site.GetPage "section" "blog" "vacations" is tethered to directory structure.
@rdwatters I have read your post twice, and I don’t get it. But I’m pretty sure that my model is solid (I’m not making changes that makes me guess where to look for stuff, where is that vacation section again? Oh, there its is …).
I would rather have the user tell me where it is. And understand this: In 99,99% of the use cases, there is no need to do .GetPage "section" "mumbo" "jumbo". You just start from the top and walk down the tree. Totally safe for changes. The GetPage approach is for the @jgreely of the world. And myself.