Add the ability to post different types of things, such as notes, publications(?), in addition to blog posts.

[cdchapman]

If we are using different kinds of items, we could create a helper for each kind of item and put each kind in a separate path. Pros of this option would include taking advantage of automatic Nanoc::Core::IdentifiableCollection memoization (see d142929). Cons would include having to write a new helper for each kind of item.

Another approach would be to write one helper (e.g. Weblog) that could be used to fetch all syndicated items, and use a parameter to delimit kinds. The pro of this is that new kinds could be added easily , the con is that the initial fetching code will be a little more complex. Actually, since we will be moving all static posts to a separate repo (#114) that is mounted at one directory (/static/posts), this fetching code will be more simple than I originally thought. Actually, we may be having more than one root for syndicated items, if we will eventually be syndicating benefit reports, events, and press releases. This would also open up the door to PESOS third-party content (such as tweets) to the site.

I prefer the second option. It is one thing to add a kind-specific layout or styling, since Nanoc dependencies are fine-grained regarding items and layouts. But changing the lib code requires a complete rebuild no matter what. It seems like we should avoid changing the site code solely for content reasons.

Implementation:

• Add tests.
• Add documentation for how syndicated items work.
• Create a Weblog helper module to deal with all syndicated items in an efficient way. Should be able to request one or more kinds of items.
• Create a syndicated_roots config value that the Weblog helper uses to pull in all syndicated items.
• Simplify or remove the Blogging helper.
• Add a twitter data source to pull in company and member tweets. #120
• Content summarization should be dependent on item kind, like layouts.

[cdchapman]

At some future point, it might be useful to implement a client-side filter (#118)