You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, for some reason I don't understand, all tags are rendered into post URLs serially. For instance, a post with tags "pinned" and "release" will end up with blog/pinned/release/<name>.
First, this suggests a hierarchy that does not make any sense. Tags don't have an order. Second, the URLs become unstable unless you maintain the tags as they are forever. As just showcased, we make mistakes with tags. For instance, our last post contained "release", although it's more of a "meta" post. Fixing this issue changes the URL unfortunately.
Unstable URLs are a problem in many cases. The following list contains a few examples:
links in the browser history render a 404
links indexed by search engines might not work any more
links contained in third-party websites will become invalid
I think we should change the way our URLs are generated. The URL should directly reflect the filename or, alternatively, the post name, perhaps adding a year and maybe even month to avoid collisions.
We also need to consider implementing some forwarding logic for the existing posts. We should not render them a second time, but instead we could probably just generate HTML pages that meta-forward to the new location. This can be done for all new posts as well, as it is unlikely to cause issues in the future.
The text was updated successfully, but these errors were encountered:
Changing the generated URL is very easy. This is done in _config.yml, the line 35. Switching it to permalink: /blog/:title/ results in URLs like http://localhost:4000/blog/newpipe-0.21.2-released/. Given that we only have unique titles so far, I dont think having non unique ones is an issue we have to migrate with a date in the URL.
What I do not understand is the generation of HTML meta forwarding pages. Where should this happen, is this something jekyll is supposed to care of or a different script somewhere? And I dont get why for new sites.
Given that we only have unique titles so far, I dont think having non unique ones is an issue we have to migrate with a date in the URL.
True. But I'd consider adding a year at least even a feature. This allows you to quickly see how old an article is. That's why I suggested adding it to the URL.
Where should this happen, is this something jekyll is supposed to care of or a different script somewhere?
Ideally, Jekyll does it right away. I'm not sure how hard it would be to render the sites a second time, or even better render second pages.
We could, if needed, add some redirections by hand to our nginx config, but that'd be quite some manual work.
And I dont get why for new sites.
Then you don't have to add a filter for which sites you need to generate those pages. Just do it for all of them. Won't hurt for new ones.
While we're at it, we could and probably should also change the tags' page URLs to include something like tag, e.g., /tag/pinned.
Right now, for some reason I don't understand, all tags are rendered into post URLs serially. For instance, a post with tags "pinned" and "release" will end up with
blog/pinned/release/<name>
.First, this suggests a hierarchy that does not make any sense. Tags don't have an order. Second, the URLs become unstable unless you maintain the tags as they are forever. As just showcased, we make mistakes with tags. For instance, our last post contained "release", although it's more of a "meta" post. Fixing this issue changes the URL unfortunately.
Unstable URLs are a problem in many cases. The following list contains a few examples:
I think we should change the way our URLs are generated. The URL should directly reflect the filename or, alternatively, the post name, perhaps adding a year and maybe even month to avoid collisions.
We also need to consider implementing some forwarding logic for the existing posts. We should not render them a second time, but instead we could probably just generate HTML pages that meta-forward to the new location. This can be done for all new posts as well, as it is unlikely to cause issues in the future.
The text was updated successfully, but these errors were encountered: