csarvenIf I arrived at that document, I'd prefer to see a 404, and then an index with links to all of the months for that year (where the current one is unlinked and greyed out).
ZegnatI would send a HTTP 404 code still, simply because there is no content there currently, and might never be (in case of backdated years/months). Serving a page with 200 OK for every possible year (theoretically starting at year /blog/0/january/) seems odd to me
ZegnatOf course for the visitor you might to offer a nice explanation text and links that do give content, but for browsers/crawlers I would still serve it as 404
csarvenHmm, well, come ot think of it. 410 may be more appropriate here because you have a good idea why it is not available. 404 is for when you don't know or don't want to indicate why it is not there.
csarvenUse 404 if you never had a post there and never will. Use 410 if you had it but removed it. Use 302 during that month, and then switch to 404 the next month.
ben_thatmustbemethey should not have been at that URL other that by typing it in. presumably if there is no link on your site, and there is no events in that timeframe, 404 would be correct
Zegnathttps://aaronparecki.com/notes/2018/01/ makes sense and is a 404. (Not picking on you specifically here aaronpk, I just happened to have your site open when I needed these examples. These things probably go for almost every site.)
ZegnatI thought that to be the case aaronpk :) It is just that things might grow out of hand when you want 404 only for non-valid URLs. /notes/2018/01/ might very well get content within a reasonable future (unlike year 3019)
aaronpkno it's quite easy, my URL pattern matcher catches URLs like /yyyy/mm and /yyyy/mm/dd, regardless of what the years and months are. but if you type in something random that doesn't match any of the URL patterns on my site it returns 404
ZegnatFuture year/date URLs on tantek.com also give status 200, just no items in the OL-element. Funny enough the layout breaks in future years because it loads the CSS relative to the year (e.g. tantek.com/2016/001/ has no CSS)
tantekI have a feeling that as a non-primary view they may have more flexibility with modifying that - especially if we can give them tests to check-in and automatically verify results
tantekthe question is - is it possible to algorithmically translate from "typical" FB permalinks to mbasic facebook permalinks - if so, that leads to some interesting opportunities
tantekI may bring all my "old" indieweb notebooks and open source all my UI sketches for user-forgiving undoable post UIs that I have *yet* to implement.
Loqitantek meant to say: I may bring all my "old" indieweb notebooks and open source all my UI sketches and user flows for user-forgiving undoable post UIs that I have *yet* to implement.
tantekeven if that doesn't get anything "built" on my own site, I'm hoping a) others might be interested, and b) we can see if there is some way to connect those user flows with micropub (i.e. does micropub allow for some way for clients to "undo" stuff at the server)
tantekthe other big itch (need to document it!) that I've got is a super-clean/slick/pretty design for "mobile" viewing of my posts and home page stream. e.g. I want it to look as good or better than how Instagram (iOS app) looks when viewing my stream of photos.
tantekand if I get that, then the next stretch thing after that is to implement tantek.com/photos - a view of only posts that include at least one photo I've taken (yeah that will be interesting to markup) no matter where the photo jpg itself is hosted (my site, IG, Flickr, s3, IWC wiki etc.)
aaronpkgRegorLove: note that I am moving *away* from having the post type as the first part of the URL despite thinking that was a great idea when I started
gRegorLoveGotcha. Maybe I'm too much into the blog mentality, since that's what my site's always been. I've always had articles and recently added notes, so /articles/ and /notes/ seemed to be the logical top level sections when I started this migration
aaronpkright now i've got basic storage and rendering of posts along with a micropub endpoint to create and edit posts, the micropub endpoint has no knowledge of post types, just some knowledge of datatypes of specific fields like "published"
aaronpkrendering the posts is where I start adding post-type-like things, such as using different templates depending on whether there is a photo or video, or sleep data, or a route
aaronpkI still want to have URLs like /articles/notes/photos/runs/sleep/food etc, so I'm adding this idea of a collection (not sure what to call it) where posts may be added to multiple top-level URL paths depending on what's in them
tantekoh hey - yeah I vaguely remember a recent discussion about slugs in IRC that mentioned something hypothesizing about how mine get generated/edited - where was that
tantekyeah in general I agree with aaronpk - drop any expliciting post typing from the URL, I can share my reasoning about why I have them in my URLs *after* the date
Loqitantek meant to say: yeah in general I agree with aaronpk - drop any expliciting post typing from permalink URLs, I can share my reasoning about why I have them in my URLs *after* the date
tantekon the "how many words" question - answer is, keep your permalinks < 70 chars for more reliable email sharing (yes, things still get broken on line boundaries in email clients, including URLs, and thus break)
tantekI agree with dropping stopwords from slugs, EXCEPT when the insertion of 1-2 of them actually makes the slug make more sense if you try to read it like a phrase or fragment
tantekfirst, what aaronpk said about any kind of /post-type/ segment. you really don't want that for permalinks. aaronpk has had to learn this the hardway so I'll let him write the big diatribe about it
gRegorLoveI was reading something on the ProcessWire forums about another CMS (name is escaping me) that used a unique ID in the path before the slug and then had "forgiving" slugs. Basically if you misspelled or had other words, it would redirect to the correct URL.