Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


Refactor access to category/tag names #29

ghost opened this Issue · 13 comments

4 participants


Adding a sorted array with all available category names as 'site.categorynames'. This allows to set up a listing of all categories.

Please pull from my repository (commit b659e9ce34cb74129650fc3e37ee5000328e9d8d).


I like this, but it definitely needs tests. On hold until someone can get around to writing them.

h3h commented

Might I humbly suggest category_list instead of categorynames?


Done: 98a468355fb1ce30b0868400963ea5fc44a66f48


Why not rework site.categories to accomplish this? So we can do like:

{% for category in site.categories %}
  <h2>{{ }}</h2>
  {% for post in category.posts %}

Initially I just needed a small fix for my site. A one-liner seemed like a good-enough solution for the time being. I initially even set out to implement Thomas idea but was too lazy, so I stuck with the one-liner.

That said, I think that a bit of re-modeling might benefit jekyll in the future (i.e. decoupling filesystem layout and reading from content transformation, changing Topic and Category into real objects, etc.).


I was able to make the snippet in my last comment work, but in order to keep working, I had to make a Categories class that acts both like a hash (mapping category names to Post arrays) and like an array of Category objects (through each).

This seems like it would become more of a problem if categories ever get more data. I'd like to be able to someday do:
{{ }}
and have it link to an automatically generated _site/[category]/index.html. But if is an array of posts, the extra category data won't be accessible from it.

Maybe we could change to


Alright, now that tags are in master I think it's time to address this issue. I like tomo's idea but I need to play around with this more. If you've got other suggestions pipe up!


If this was to be refactored, I think it would need to degrade gracefully. For instance I think at least until 0.6.0 or 0.7.0 the site object would have to work as normal. There could then be a new object, perhaps jekyll or another name that makes sense with the refactored payload.

Or maybe this could be done through a config value... payload: new and default to old, print out plenty of warnings in the meantime.


I really like tomos idea. I like to have a strong domain model at the heart of my programs and his idea goes along the same lines. My suggestion is: Follow tomo and drop in favor of


Btw: I created a wiki page ( ) that discusses API-breaking changes. Please contribute to the page.


I think we're good on this, no?


This is super old. Closing it down.

@qrush qrush closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.