Define behavior for is_post / posts

[epage]

Goals

• Make rss / jsonfeed paths available to theme (RFC Reusable themes #301) / layout
• Able to iterate on sorted posts for indexes
• Can have title/description distinct from non-blog posts
• Can be reused for collections
  • dedicated title, description, feed information, indexable
• Minimal complication for non-collection use case
• Minimal layout / theme complication

Use cases

• A page that is an index of posts
  • ditto for collections
• A post snippet that is a menu of posts
  • ditto for collections
  • Particularly a generic one
• A post snippet that links to the RSS
  • ditto for collectons
  • Particularly a generic one
• A page snippet that links to the posts RSS
  • ditto for a collection's RSS

Proposal

• page.collection: Slug of the collection
• collections.
  • title
  • description
  • rss_permalink
  • jsonfeed_permalink
  • pages

Use case solutions

Use cases

• A page that is an index of posts: {% for post in collections.posts.pages %}
  • ditto for collections: {% for dog in collections.dogs.pages %}
• A post snippet that is a menu of posts: {% for post in collections.posts.pages %}
  • ditto for collections: {% for dog in collections.dogs.pages %}
  • Particularly a generic one
• A post snippet that links to the RSS: {{ collections.posts.rss_permalink }}
  • ditto for collectons: {{ collections.dogs.rss_permalink }}
  • Particularly a generic one
• A page snippet that links to the posts RSS: {{ collections.posts.rss_permalink }}
  • ditto for an collection's RSS: {{ collections.dogs.rss_permalink }}

Prior Art

Cobalt today

• posts have
  • posts: list of post attributes, containing everything but content / excerpt
  • is_post: boolean to know this s a post
• pages have
  • posts: list of post attributes, containing everything
  • is_post: boolean to know this isn't a post

Hugo

Pages have:

• RSSLink for taxonomy (collection?) the page is in
• Site.RSSLink for site's rss
• Site.Taxonomies.<name>.Pages: list of pages
  • within a taxonomy, these are available as .Data.Pages

Hugo

Jekyll

Page attributes

• site.posts: list of posts
• site.<name> list of pages
  • epage: We're trying to avoid mixing user-provided data with cobalt data to avoid breaking users on new additions
  • epage: Also, not all collections will be sorted, making this field type not always relevant.
• site.collections.<name>: collection metadata (name, list of pages, etc)
• collection: name of containing collection

Permalink

• :collection name of the collection

Variables

[epage]

The breaking change in here is that we'd need to switch posts from being just a list to being an object. that has a list child item

[epage]

Initial thought:

• collection: metadata for current collection, including list of pages within it
• (pages outside of any collection): collections.<name>: metadata for the given collection, including list of pages within it

Under this

• is_post translates to collection.slug == "posts"
• posts (within a post) translates to collection.pages
• posts (in a non-collection page) translates to collections.posts.pages

Pros

• Collections can reuse menus
  Cons
• A bit verbose for the index pages
• Makes it tricky to have a menu of posts shared between a page and a post
  • Example: site and source
  • Would require a {% assign collection = collections.posts %}
• Can't show menu of posts on other collections

[epage]

One option is to make collections available on all pages, just without page.excerpt and page.content.

But then it feels weird to have both collection and collections.<name> be the same thing.

But collection is nice for

• Knowing what collection you are in (can be handled by a page.collection)
• collection.pages is easier than collections[page.collection].pages (which liquid-rust doesn't even support yet, see Allow expressions in indexed variables liquid-rust#145)

[epage]

Jekyl''s where filter seems to be helpful: {{ site.collections | where: "label", "myCollection" | first }}

See #350 for adding it in.