Fri 07 October 2016
Status: Success! But more on that later…
I would like to have a category of blog posts called ‘meta’, with tags ‘changelog’ and ‘todo’. This category and those tabs would describe changes to the site itself, and while I want to be able to see those posts by visiting the category meta, I would prefer those posts not appear on the default site page.
It seems there are two places to filter out such posts, inside of Pelican itself, or inside of the specific template for the index page. With digging though it seems neither is the right place.
Pelican refers to posts as articles. Filtering out articles within the templates has pros and cons. The pro is that index has its own template, so placing the logic in the index template ensures the logic is limited to that template, the con being that the logic in that template then has to be ported over to any other templates the site is rendered with. And then alas, the way the index page is considered a paginated page in Pelican, rendered by instantiating the template many times, one for each page of posts and each time with a new range of articles to render. And so filtering the articles within the template logic yields pages with inconsistent numbers of posts. In fact, some pages might even have no posts at all.
So that leaves modifying Pelican.
Within Pelican there is nothing special about the index template. It is just one “direct template” of many. So filtering the posts within Pelican means adding special case logic to distinguish when it is rendering the index page from other templates. It can be done, but it’s not the sort of change I want to make right now. I’d prefer any changes I make to Pelican itself be changes I would give back to the project and changes the project would want to incorporate. I don’t see this as that at the moment.
Perhaps one way to do this would be to add a blinker (a python pubsub library) signal to Pelican’s existing signals to be sent for every template as it is about to be rendered. And then a developer could receive that signal and determine if the current template is one he wishes to modify that global context for, and then modifies it and lets the template run, … and then unmodifies that global context for the next guy. Well, that’s ugly, and not a way to do it at all!
Perhaps I should rethink my desire to leave the meta and changelog posts out, or change my thinking on how to document changes and meta descriptions of this blog. :(
On the upside, spent a few days with the pelican internals leading to all sorts of fun with
- git and github