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

onBrokenLinks throw errors when linking to an external static html page #9758

Closed
1 task
jbltx opened this issue Jan 17, 2024 · 11 comments · Fixed by #9788
Closed
1 task

onBrokenLinks throw errors when linking to an external static html page #9758

jbltx opened this issue Jan 17, 2024 · 11 comments · Fixed by #9788
Labels
bug An error in the Docusaurus core causing instability or issues with its execution

Comments

@jbltx
Copy link

jbltx commented Jan 17, 2024

Edit from @slorber: the bug/repro is about a static/my-route/index.html resource and navbar item linking to it with a target:

        {
          href: '/my-route',
          label: 'My Route',
          prependBaseUrlToHref: true,
          target: '_blank',
          position: 'left',
        },

Links with a target: "_blank" should not be checked because they are unlikely to be internal SPA links.

Description

After upgrading from 3.0.1 to 3.1.0, the onBrokenLinks feature throw exception on static routes while it was not the case before.

Reproducible demo

https://stackblitz.com/edit/github-fausgf

Here is a fork of the repro project but using 3.0.1 without errors: https://stackblitz.com/edit/github-fausgf-qpa5vb

Steps to reproduce

  • Create a new Docusaurus project
  • Create a simple index.html file inside a subfolder in static directory
  • In the Docusaurus config, add a NavBar item to link to this static html page
  • Try to do a production build using npm run build
  • Observe thrown errors during server compilation

Expected behavior

Does not throw errors for static page links (like in 3.0.1)

Actual behavior

Throw errors for static page links

Your environment

  • Public source code: None
  • Public site URL: None
  • Docusaurus version used:3.1.0
  • Environment name and version:Node 18.17
  • Operating system and version:MacOS 14.2.1 and Unbuntu 22.01

Self-service

  • I'd be willing to fix this bug myself.
@jbltx jbltx added bug An error in the Docusaurus core causing instability or issues with its execution status: needs triage This issue has not been triaged by maintainers labels Jan 17, 2024
@slorber slorber removed the status: needs triage This issue has not been triaged by maintainers label Jan 18, 2024
@slorber
Copy link
Collaborator

slorber commented Jan 18, 2024

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,

@andrewgbell
Copy link

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
Copy link
Collaborator

slorber commented Jan 24, 2024

@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
Copy link

@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
Copy link
Collaborator

slorber commented Jan 24, 2024

@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.

@slorber slorber changed the title OnBrokenLinks throw errors with static HTML pages in production builds OnBrokenLinks throw errors when linking to an external static html page Jan 24, 2024
@slorber slorber changed the title OnBrokenLinks throw errors when linking to an external static html page onBrokenLinks throw errors when linking to an external static html page Jan 24, 2024
@andrewgbell
Copy link

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
Copy link
Collaborator

slorber commented Jan 25, 2024

@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
    1. 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)

@slorber
Copy link
Collaborator

slorber commented Jan 25, 2024

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
Copy link
Collaborator

slorber commented Jan 25, 2024

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

@anonhostpi
Copy link

anonhostpi commented Sep 1, 2024

I'm getting this issue when I add html files to static.

Currently, I have a static html file known as playground.html.

If I try to access playground.html, directly using the URL bar, it loads up fine, but any links I create to it in the docs not only show up as broken while compiling, they also redirect the user to the 404 page, if the user clicks them.

What's funny is that the URL that opens when they click it is the correct URL.

@anonhostpi
Copy link

A temporary workaround is to add the aformentioned target: '_blank'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An error in the Docusaurus core causing instability or issues with its execution
Projects
None yet
4 participants