New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order of hierarchical/categories should match source folder layout #33

Closed
jrk opened this Issue May 5, 2009 · 6 comments

Comments

Projects
None yet
5 participants
@jrk

jrk commented May 5, 2009

Jekyll's inference of flat category and topic spaces from trees of parent folders (above and below _posts, respectively) is potentially useful. However, where categories are reflected in the generated URL structure (which they are by default, which is good), the generated directory structure should mirror the source structure, not be re-nested as some arbitrary ordering of categories.

In my case, under my Jekyll root, I have:

projects/
    aProject/
        _posts/
    anotherProject/
        _posts/

and in the generated _site this yields:

projects/aProject/year/month/day/some-post

AND

aProject/projects/year/month/day/some-post

with the default url for the post (which gets inserted in templates referencing that post) being in reverse order, pointing to the latter:

aProject/projects/year/month/day/some-post

This is unintuitive in two respects:

  1. Generating the combinatorial set of possible paths to each post is unexpected.
  2. Having the default path/permalink include a different (perhaps arbitrary) hierarchical ordering of categories is unexpected and undesirable.

It is common to want some degree of hierarchy in a generated site. It only makes sense for the source hierarchy to be mirrored for posts (where it is mirrored at all -- I understand and respect that topic directories are meant to be handled separately, and not reflected in the generated directory structure), just as it is for generated non-post pages and other content. Supporting this more predictably is arguably much more valuable than any clever tricks to interpret hierarchical filesystem layout as implying a flat tag space, and even where those tricks may be useful, I maintain that this is logically something which should distinguish topics (tags) from categories ("folders").

@qrush

This comment has been minimized.

Contributor

qrush commented May 8, 2009

Agreed, this shouldn't be too hard to implement (or test). If you or someone else wants to wrap up a patch (with tests) I'll be glad to merge it in.

@qrush

This comment has been minimized.

Contributor

qrush commented May 18, 2009

jrk,

Is this still valid given the topics and tags changes that I've just pushed? Let me know, thanks!

@tomjack

This comment has been minimized.

Contributor

tomjack commented Jun 9, 2009

Got this working at http://github.com/tomo/jekyll/tree/hierarchical_categories, last 2 commits.

The features and tests assumed that categories would show up in the URL in alphabetical order. I changed them to assume that categories should show up in the order specified by the directory layout or in the YAML.

@jrk

This comment has been minimized.

jrk commented Jan 7, 2010

I've left this dormant forever, but yes, this is still a half-valid issue: specifically, the sort applied to the category list during permalink generation is nonsensical and coerces /my/filesystem/order in the filesystem into /filesystem/my/order in the permalink for no clear reason, and with substantial surprise to the user.

@jrk

This comment has been minimized.

jrk commented Jan 7, 2010

To be clear, a patch as trivial as tomo/jekyll@0a1e3cd2508c797d7b8d1038636a6e7111e5cd3d really does fix this. (I've done the same on top of the current trunk in jrk/jekyll@8531f25 )

@mojombo

This comment has been minimized.

Contributor

mojombo commented Jan 15, 2010

Merge commit '0a1e3cd2508c797d7b8d1038636a6e7111e5cd3d'. Closed by a4f3f5c.

Conflicts:
features/post_data.feature

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.