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

Allow sorting by weight/order #14

Closed
Keats opened this Issue Mar 25, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@Keats
Copy link
Collaborator

Keats commented Mar 25, 2017

Sections and some content don't have dates but we will want to order them somehow. Having weight in the front-matter might do the trick (lighter -> top, heavier -> bottom).

Sections should be able to define how they want to be sorted though. In the _index.md frontmatter, we can add a sort_by key that takes either "date" or "weight".
An alternative is to add a sort_by filter that can handle that from the template itself.

Probably going to wait for some feedback before starting this.

@Keats Keats modified the milestone: 0.1.0 Mar 25, 2017

@Keats Keats changed the title Allow sorting by weight Allow sorting by weight/order Apr 20, 2017

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Apr 20, 2017

Sorting by order rather than weight might make more sense:

1 -> bottom
2 -> above 1
3 -> above 2

The advantage is that adding a new page doesn't require potentially changing weights of other pages unless you want to put something in the middle

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Apr 22, 2017

Looks like having _index.md for the homepage will be better than just putting all index specific data in the config

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Apr 22, 2017

Homepage _index.md in #45

Frontmatter should have a sort_by that defaults to "date" and can take "order" and "none" as value as well.

Any content without a date or an order (depending on the current section sort_by) will be put at end of the list. The prev/next for those would be kind of random, not sure it's what we want but i don't see a solution other than just ignoring them.
Ignoring them would solve the issue of having static pages mixed with the content in the index page though: for example on my site I have an about and project pages that I don't want to show when iterating on the blog posts or consider at all when paginating/setting prev and next. A warning could be shown if necessary but not for the index page.

This was referenced Apr 22, 2017

Keats added a commit that referenced this issue Apr 24, 2017

Keats added a commit that referenced this issue Apr 24, 2017

@phil-opp

This comment has been minimized.

Copy link
Contributor

phil-opp commented Apr 25, 2017

I have an about and project pages that I don't want to show when iterating on the blog posts or consider at all when paginating/setting prev and next

This seems to be a common problem. Some static site generators solve this by arbitrarily dividing pages into "posts" and "pages". I don't really like this solution because it is inflexible.

A more general solution would be a method to retrieve a section by name. Then we could iterate over all pages of a posts section that is ordered by date and maybe even iterate over pages of a footer section that contains pages like about or contact and has manual ordering.

I don't like the none ordering, since a random ordering would make the output non determistic. Instead we could probably order by e.g. file creation date.

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Apr 25, 2017

I don't like the none ordering, since a random ordering would make the output non determistic. Instead we could probably order by e.g. file creation date.

The none is for designing landing pages for example, where you don't want any kind of ordering. It matters if we want to avoid warnings (see below).

A more general solution would be a method to retrieve a section by name. Then we could iterate over all pages of a posts section that is ordered by date and maybe even iterate over pages of a footer section that contains pages like about or contact and has manual ordering.

The index page on gutenberg gets all the sections so that's already doable.
I think pages that don't have dates/order when their section is ordered by date/order should not appear at all. It should display a warning saying this page will not be present because it doesn't have a date/order, unless sort_by is set to none. It will still display a warning in the case of a blog with a couple of non-ordered pages but I think this is ok.

@phil-opp

This comment has been minimized.

Copy link
Contributor

phil-opp commented Apr 25, 2017

The index page on gutenberg gets all the sections so that's already doable

Great!

It will still display a warning in the case of a blog with a couple of non-ordered pages but I think this is ok.

Hmm, so to fix these warnings, one has to put all non-ordered pages in a separate section?

@Keats

This comment has been minimized.

Copy link
Collaborator Author

Keats commented Apr 25, 2017

Hmm, so to fix these warnings, one has to put all non-ordered pages in a separate section?

I think so. i already organise things roughly like that myself: https://gitlab.com/Keats/vincent.is/tree/master/content
An alternative would be putting an attribute in the front-matter to disable the warning but I don't really want to go down the path of adding tons of things there.

Either way, I'll make the warning not too annoying and it should only appear when rebuilding index/section pages so it shouldn't come up too often even if you choose to ignore them.

Keats added a commit that referenced this issue May 1, 2017

@Keats Keats closed this in #47 May 1, 2017

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