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
[new docs site] relative links on URLs with and without a trailing slash #15844
Comments
The example with related rules no longer applies since those links now start with For example, links on this page work well: https://new.eslint.org/docs/user-guide/configuring/ But, if user opens this (no trailing slash): https://new.eslint.org/docs/user-guide/configuring the underlying In addition to broken links, this might affect SEO. Related issues: |
@mdjermanovic In the below image configuration, command line interface and integration links redirects to 404 page I have created a draft pr #15919. I would like to work on this. Can I find and fix the broken links? |
On the current site, this page is https://eslint.org/docs/user-guide/getting-started (without trailing slash). Relative links on the page were set based on the URL without the trailing slash, and the current site redirects https://eslint.org/docs/user-guide/getting-started/ to https://eslint.org/docs/user-guide/getting-started, so it always works well. On the new site, redirects don't work, and with the trailing slash in https://new.eslint.org/docs/user-guide/getting-started/ relative links on the page are broken.
I think we should decide on the approach first. Some ways to address this might be:
|
In our case can't we use netlify’s Pretty URLs feature by any means? if not then we can consider 3rd option (Allow all URLs with and without a trailing slash) |
I think the first step here should be to find what is different between the current site setup and the new site setup. We are using the same source files so we should be able to generate the same files to deploy. If we aren’t, it’s probably a misconfiguration in Eleventy. |
I prepared PR #15967 that should fix this, files will be generated in the same way as on the current site. That should help with using the expected URLs (those where document-relative links on the page work as intended) in the docs index, sitemap and But we'll still have duplicate content and broken links on "wrong" URLs due to the absence of redirections with proxying (#15844 (comment)). |
I’ll take a closer look at the proxying issue. |
Enabling pretty URLs on the prototype docs site seems to work as-is: I also enabled it on in-repo docs site, and we don't get 404s, but each URL loads separately: It seems like at this point we can probably experiment with URL rewrites on new.eslint.org to solve this problem? Note: In both pages on new.eslint.org, the canonical URL is set to with a trailing slash because both URLs actually go to the same file. |
Ideally, https://new.eslint.org/docs/rules/no-cond-assign/ would 301 to https://new.eslint.org/docs/rules/no-cond-assign, the same as it currently works on eslint.org. If that's not possible with proxying on Netlify, I think the next best option would be to return 404. Would disabling Netlify's Pretty URLs option on docs-eslint.netlify.app achieve this? If neither 301 nor 404 is possible to set up, i.e. if both URLs will always return 200 with the same content, we might need to ensure that all links on all pages have domain-relative URLs so that it doesn't matter whether or not the request URL had a trailing slash. |
I don't think we are going to be able to get the exact same behavior as the current site, and I think that's fine. There's no reason to believe the current behavior is any more correct than any other behavior so long as people can find the content they are looking for. Most sites operate with a trailing slash on their URLs, so I'm not too worried about it. As long as the canonical URLs are correct, I think we will be set.
I don't like this approach. We are penalizing the user, who likely arrived here through no fault of their own, by returning a 404.
Can you explain what you mean here? I'm not quite sure I follow. |
I dug into this a bit more -- Netlify doesn't allow you to add or remove trailing slashes using redirects. I'm not sure if this matters much as long as we put in canonical URLs, especially because we will be changing from However, we can certainly see if we can get a behavior closer to what we have already by merging #15967 and keeping pretty URLs on. I think that will give us the desired result, but it's hard to know without actually deploying and testing it out. |
If both URLs return the same content, and that content has document-relative links, on one of those two URLs those links will be broken.
|
This is still an issue. For example, all relative links on https://new.eslint.org/docs/latest/user-guide/configuring are broken. The sidebar link, sitemap, and Canonical URL will all point to This is a realistic example. Before #13837, |
I wonder if we can handle this case with specific redirects instead of the generic ones? Otherwise, I think it’s time we just go through and update the markdown files to have fully qualified URLs. I’m pretty sure we can use the Nunjucks url filter in markdown. Do you have other ideas? |
Redirects are the best practice for the trailing slash problem, but even if this is feasible they would have to be stored in new.eslint.org repo and basically every URL is problematic so it could be difficult to maintain.
Given what options we have until Netlify provides some built-in solution, this might be the best choice.
We could maybe try out |
Ooh, Alternate approach: if (!/(?:\/|\.html)$/.test(location.href)) {
history.replaceState({}, "", location.href + "/");
} |
* fix: Set base URL on pages so relative URL links work Fixes #15844 * Use relative base URL
Environment
main
branch,npm start
in thedocs
directory.What parser are you using?
Default (Espree)
What did you do?
Open USER GUIDE > Rules > no-cond-assign. Then, in the Related Rules section click no-extra-parens link.
What did you expect to happen?
To open no-extra-parens document.
What actually happened?
The link is broken as it points to
rules/no-cond-assign/no-extra-parens
.Participation
Additional comments
This is caused by writing
rules/no-cond-assign.md
torules/no-cond-assign/index.html
, unlike the current site where it isrules/no-cond-assign.html
. The path on the new site isrules/no-cond-assign/
(with/
at the end) as opposed to the current site where it isrules/no-cond-assign
(without/
at the end) so the relative links in the document are broken.The text was updated successfully, but these errors were encountered: