Pelican: Add support for generic content types

[nurupo]

With Pelican it's possible to have a website consisting of static pages and a blog, which is great, however websites often need to provide more blog-like (collections-like) content, like reports, events, docs, etc. Jekyll supports this but I can't find any support of it in Pelican (perhaps it's implemented as a plugin?).

The way Jekyll does it is that you can specify a directory containing a "collection" - a set of posts, and they will be accessible in templates as site.<collection-name> variable, and you can add metadata to the front matter of those posts which is accessible as site.<collection-name>[index].<metadata-name>. It's very simple yet useful. While I don't think Jekyll does this, it would be great if Pelican could optionally generate rss/atom feeds for collections, and maybe optionally generate author, date and tag pages similar to how it does for the blog. Collections can pretty much be treated like multiple instances of blogs, with ability to turn off some blogging features like feed and special pages generation. In fact, starting with Jekyll v3, there is supposedly no difference between blog pages and collections, it's all the same.

It's true that you can "hack" together a workaround for this by making your website consists of multiple Pelican blogs, but that's kind of ugly and you wouldn't be able to access all of the blogs (collections) in a single template, e.g. you can't have an index page that has multiple columns listing your recent news, blog posts, events and recently changed docs, as the index page would have access only to one blog (collection). So I think a proper solution for this is needed.

[justinmayer]

There is a lot of overlap between what is described here and the existing Category functionality. It would be helpful to elaborate precisely how using categories in its current form falls short for a specific (preferably actual and real) use case.

[avaris]

While I do see the benefit [] of having generic content types, it would be a signifcant refactoring of the pelican internals. It is really difficult to make this change without breaking *a lot of the plugins. So, it is a major breaking change.

In the meantime, there is Entities plugin that kind of implements it. But it simply cannot use any plugin dealing with ArticlesGenerator or PagesGenerator.

[*] Even if you leave out the benefits for user, it'd be a nice cleanup of the pelican core and would eliminate some duplication.

[justinmayer]

@nurupo: Would you be interested in working on adding support for generic content types, along the lines of what @avaris mentioned?

[nurupo]

Sorry, not interested in contributing to Pelican until it is under a more permissive license, e.g. MIT. That said, this being a major braking change might be a good opportunity to do a re-write.

I'm sticking with Jekyll for now. Even though I'm not a fan of Ruby language and dislike Liquid templates (they don't even support inheritance!), I like everything else about it. An almost 1-to-1 Jekyll clone written in Python, using Jinja2 templates, and having the ability to extract data from file paths like Pelican can, would be just what I want though.

[justinmayer]

Got it. Cheers.