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

Make tox.chat/download redirect to tox.chat/download.html #207

Open
sudden6 opened this issue Oct 19, 2018 · 5 comments
Open

Make tox.chat/download redirect to tox.chat/download.html #207

sudden6 opened this issue Oct 19, 2018 · 5 comments

Comments

@sudden6
Copy link
Contributor

sudden6 commented Oct 19, 2018

Would be a handy shortcut.

@nurupo
Copy link
Member

nurupo commented Oct 19, 2018

It's a static website, so that would mean creating a link of download.html at download/index.html, and if we do it for download.html, we have to do it for all other pages too.

@sudden6
Copy link
Contributor Author

sudden6 commented Oct 19, 2018

can't we just change /download.html to be download/index.html? should have the same effect, right?

@nurupo
Copy link
Member

nurupo commented Oct 19, 2018

That's what I have said, creating a symlink download/index.html pointing at download.html. We can't delete the original download.html because other websites out of our control still link to it, we have to keep it. We'd also need to do this for all pages, e.g. symlinking clients.html -> clients/index.html, for consistency.

@sudden6
Copy link
Contributor Author

sudden6 commented Oct 19, 2018

Ok, sorry misunderstood the answer then. Also didn't think about existing links. So could this be done?

@nurupo
Copy link
Member

nurupo commented Oct 19, 2018

Right, if it was a new website that no one was linking to yet, then I'd go with tox.chat/download over tox.chat/download.html, as it looks nicer, less to type and doesn't imply that its a pre-generated html file, one day it could be a php script and another a route in a Flask web application without raising eyebrows, but since we have been using .html URLs for over 3 years now and websites link to them, breaking all those links for "would be a handy shortcut" reason is a bit too unjustified, someone would try to open "download Tox" link from some other website and would get "HTTP 404 File not found" back, which is not nice, so if we do tox.chat/download we also need to keep tox.chat/download.html. We could probably do this with some nginx configuration magic, but it being a static website I'd like to solve these things on the fs level as static websites generally don't have access to the webserver configuration (heck, you can't even setup a 301 redirect on GitHub Pages, which would be very useful for hosting Flatpak repositories on the combination of GitHub Pages + GitHub Releases).

So while I'm not a big fan of it, I tolerate our current situation of having only .html URLs, given that we can't remove and replace them with non-html URLs, and that adding non-html URLs in addition to html URLs would require more work testing any website changes making sure that they work for both page URLs (due to relative links and all that).

I was thinking about the possibility of changing URLs in favor of non-html versions in the website update PR (#199), it sounds more justifiable in this case since with that PR we will also be breaking blog URLs and possibly other things, but given how I lost the interest in working on that PR after waiting a couple months for robinli's changes (just to make it clear, I don't blame him for anything, it's volunteer work -- and for the record he did deliver after he got time for it -- I blame myself for losing the interest over time) and forgetting the Jinja/Pelican stuff, I'm not sure when I'm going to come back to finishing that PR, so we might as well introduce the non-html URLs now rather than wait who knows how long. Feel free to open a PR with the appropriate changes.

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