Skip to content
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

Rendering tags into URLs makes them unstable #233

Open
TheAssassin opened this issue May 27, 2021 · 2 comments
Open

Rendering tags into URLs makes them unstable #233

TheAssassin opened this issue May 27, 2021 · 2 comments

Comments

@TheAssassin
Copy link
Member

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.

@Poolitzer
Copy link
Member

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.

@TheAssassin
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants