Update URL scheme

[aaronpk]

Having the post type as the top-level segment of the URL is bad.

Currently considering between these options as the post identifier:

• /YYYY/mm/dd/tn (type-char and index)
• /YYYY/mm/dd/n
• /YYYY/mm/dd/HHMMSS
• /YYYY/mm/dd/HHMMn (minute-level precision and numeric index)

In all cases, a slug after the identifier is optional and has no effect on which post is loaded. I will continue to send an HTTP redirect from identifier-only to identifier-with-slug, and identifier-with-wrong-slug to identifier-with-slug.

Also need to figure out how this translates to my short URLs. (e.g. aaron.pk/DDDtn rather than tDDDn)

Also see discussion around http://indiewebcamp.com/irc/2015-02-20#t1424471093097

[aaronpk]

With the /YYYY/mm/dd/tn option, n would increment per post type rather than globally.

This means I may have an article such as /2015/02/18/a1 and several bookmarks from the same day like /2015/02/18/b1, /2015/02/18/b2, etc.

My current most frequent post type is food (metrics) so I would end up with a lot of URLs like /2015/02/18/m13. Currently I also have car2go, biking and running as "metric" posts, but I could change those to another post type.

[aaronpk]

One of the benefits of having the post type in the URL is it indicates to the reader what the content might be before they click the link. Having a single character indicate post type is likely not going to be easily recognized by the reader.

Articles are fine because I will just make a slug for them based on the title.

Many of my notes and photos contain hashtags, which I already use for the slug.

Posts like car/bike/run usually don't have any additional info I can use for the slug, so I might consider automatically setting a slug on those of "car2go" "bike" "run" so that the full URL for a plain bike ride would be /2015/02/19/m1/bike and for a run where I entered a hashtag would be /2015/02/19/m1/beat-the-blerch.

[tantek]

Thoughts on this topic (most > 5 years old, a few recent edits) http://tantek.com/w/Whistle#whyonelettercontenttypecodes

[aaronpk]

At this point I'm pretty sure I'm going to go with this option:

• /YYYY/mm/dd/n/
• optional slug: /YYYY/mm/dd/n/slug

No post type, and day is the most granular date part.

The trailing slash is important because files associated with the post are stored in a subfolder. When both the slugless and slug version share the same base path, it makes relative links to associated files possible.

The date part is the date the post was created. The index n will be a sequential number based on the sequence the posts were published on the server on that day. This means ultimately the URLs may be out of order based on the date the post was created (e.g. if posts were created offline and published to the server later).

This is a deliberate mixing of created and published dates. Ideally my URLs would be in created order, but that is not possible when posts are created on multiple devices, some of which may be offline. Having the URLs in published order seems weird, because that wouldn't represent my experience in creating the posts, and I quite often refer to the partial-date permalinks to see all posts I created in a month or a day.

[aaronpk]

Additionally, for posts that have a start date themselves (such as events, runs, sleep, etc) I actually want the URL to contain the start date rather than the created or published date.

[tantek]

That makes sense. I'd already made that decision for my events on my site, but you're right about the others as well. In that way the post represents the actual thing that is happening / happened rather than meta about it.

[aaronpk]

This is done in the new site. Documented here: https://docs.p3k.io/