-
Notifications
You must be signed in to change notification settings - Fork 64
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
Add redirects for old doc page URLs #48
Comments
Yes, this is an unfortunate consequence of updating the docs. Maybe we should have versioned somehow but it's also good users notice docs have changed. Redirects would be a good idea but that would require some time because as you say there's no always 1:1 correlation between sections, so we cannot establish a priority for that at the moment. |
I've gone through and figured out what sections correlate with each other, which should save someone some time in setting up the redirects. Here's a list of old doc URLs where what they should be redirected to is obvious:
Note that the old URLs are Here are the old doc URLs that do not have an obvious redirect, and probably indicate a missing section in the new docs that should be added at some point (I might open a new issue for that):
For anyone wanting to work on copying info from the old docs, commit |
Thanks for this @rmunn. The problem is now how to make the redirects :) The only redirect that fable.io has at the moment is the 404.html page. Not sure what would be the mechanism to have a more fine-grained mechanism as there's no actual server. I once tried to do it with JS but for some reason it didn't work there. However it seems to work with specific pages (like this one) so we could put the old doc pages and make them redirect to the new ones. About the old information:
|
What my brief research has turned up about redirects in GitHub Pages is an article at https://help.github.com/en/articles/redirects-on-github-pages that no longer exists — that URL now redirects to https://help.github.com/en/articles/about-github-pages-and-jekyll instead. The archived version of that page suggests using the Jekyll Redirect From plugin: you would add the following to the site's plugins:
- jekyll-redirect-from And then at the top of the target page: ---
redirect_from: "/foo/"
redirect_from: "/bar/"
--- Now, I don't know if this will actually work, because GitHub apparently maintains a list of supported plugins ("GitHub Pages cannot build sites using unsupported plugins. If you want to use unsupported plugins, generate your site locally and then push your site's static files to GitHub."), and I don't know whether the Redirect From plugin is still on their whitelist or not. The fact that they removed the https://help.github.com/en/articles/redirects-on-github-pages page might mean that they no longer support that plugin, or it might just mean that they folded that info into the main "About GitHub Pages" page; I can't tell. But it's worth a try. Note that if the Redirect From plugin works, that won't solve the issue of URL fragments having changed names between the old and new docs, e.g. the <a id="Dynamic-typing"></a>
### Dynamic typing: don't read this! |
Now that the new Fable docs are available at https://fable.io/docs/, some URLs scattered around the Web are broken. It would be nice to provide a way to redirect requests for the old URLs to go to the new URLs, perhaps keeping the same fragment identifier in the rewritten URL.
For example, https://github.com/fable-compiler/Fable/blob/8f10128dbd6e0d7c648dd9fd97eef028b337bf36/src/Fable.Core/Fable.Core.Types.fs#L101 mentions the URL http://fable.io/docs/interacting.html#Erase-attribute in a comment. That content is now at https://fable.io/docs/communicate/js-from-fable.html#Erase-attribute, so it would be nice if http://fable.io/docs/interacting.html#Foo would redirect to https://fable.io/docs/communicate/js-from-fable.html#Foo for all values of Foo. (Some headings in the old document may not have corresponding headings in the new document so some of those fragment identifier redirects might be broken, but in that case it would just go to the top of the page, so nothing is lost by trying to preserve the fragment identifier.)
The text was updated successfully, but these errors were encountered: