onBrokenLinks throw errors when linking to an external static html page

[jbltx]

onBrokenLinks throw errors when linking to an external static html page

[slorber]

Thanks for reporting, I see where the issue is coming from, we'll fix it 👍

In the meantime, you can use this on your navbar item: 'data-noBrokenLinkCheck': true,

[slorber]

Going to close this issue as part of #9788

---

@andrewgbell I'm not able to understand case 2 either, so if there is a problem I don't see, please open another issue with a repro.

[slorber]

The 2nd case (trailing slash url being reported) will probably be fixed in #9791

[andrewgbell]

Just to add that now we're moving to 3.1 we've noticed a similar thing. We have three different docs sources in our site and linking from one to another throws the warnings (was fine in 3.0.1 and earlier).

[slorber]

@andrewgbell is your link having target: "_blank" too?

Because it wasn't mentioned in the original issue, but it's what matters to me here.

If the link is always opened with such target, then we never navigate through a "soft/SPA navigation" and it's always a full page reload, so it doesn't make sense to check for broken links for such links with targets.

If your link does not have a target, please share another repro so that I understand the case better

[andrewgbell]

@andrewgbell is your link having target: "_blank" too?

Because it wasn't mentioned in the original issue, but it's what matters to me here.

If the link is always opened with such target, then we never navigate through a "soft/SPA navigation" and it's always a full page reload, so it doesn't make sense to check for broken links for such links with targets.

If your link does not have a target, please share another repro so that I understand the case better

No, we don't have that. The repo is private, however I can grant you access if that works for you?

[slorber]

@andrewgbell even if the repo is private, what prevents you from creating a smaller repro where I can clearly see which topology of link gets reported?

Giving me access to your repo is fine, but if I need to spend 2 hours figuring out a complex setup and identifying which link exactly we are talking about, I'm less likely to solve the problem.

I'll close this issue links with target are not checked by our broken link checker anymore. If you have another case, that's probably worth opening a different bug report with a repro so that we don't miss that case.

[andrewgbell]

This seems to have been resolved now by two things. 1, running the latest canary, 2, then adding a trailing slash after support below in docusaurus.config.js from
to: "/support",
to
to: "/support/",

(it wasn't needed in earlier versions, but maybe we were just lucky):
` footer: {

  style: "dark",
  links: [
    {
      title: "Docs",
      items: [
        {
          label: "label1",
          to: "/label1/1/",
        },
        {
          label: "label2",
          to: "/label2/2/",
        },
        {
          label: "Support",
          to: "/support/",
        },
      ],
    }

,`

[slorber]

@andrewgbell

This seems to have been resolved now by two things.

Great, but unfortunately I don't even know what the issue is in the first place.

What problem has upgrading to canary resolved?

1, running the latest canary, 2, then adding a trailing slash after support below in docusaurus.config.js from /support to /support/

I see where this trailing slash problem might come from.

But that would help to have a runnable repro to be sure we are talking about the same thing. Not seeing things such as your trailingSlash config and md docs creates an ambiguity, and I won't be sure to solve exactly the problem you encounter.

---

So:

• 1. I still don't know what the original issue is about
• 2. It's possible that my perf optimizations introduced a regression

These are 2 separate issues that both need to be solved.

Can you please create a smaller repro detailing both?

(I have no idea for case 1, and only have a guess for case 2)