Skip to content

relative paths of links in sidebar should be relative to the sidebar file #1684

Description

@ruanqizhen

Bug Report

The relative path should always based on the file that quote it.

For example, the path (foo) in file bar.md should always point to the foo.md file that in the same folder of bar.md.
But the current mechanism of relative path is based on the current url. That means if the current url is in folder xxxx, the (foo) in file bar.md file will point to the foo.md in folder xxxx.
That means the relative will never work if you have a sidebar with multiple layer of documents.

I hope this could be fixed in the next docsify version.

Other relevant information

  • Bug does still occur when all/other plugins are disabled?

  • Your OS:

  • Node.js version:

  • npm/yarn version:

  • Browser version:

  • Docsify version:

  • Docsify plugins:

Please create a reproducible sandbox

Edit 307qqv236

Mention the docsify version in which this bug was not present (if any)

Activity

  1. trusktr commented on Dec 7, 2021

    @trusktr
    Member

    Hello @ruanqizhen What you described seems to be what the doc says:

    https://docsify.js.org/#/configuration?id=relativepath

    Can you make a reproduction?

  2. ruanqizhen commented on Dec 7, 2021

    @ruanqizhen
    Author

    Hello @ruanqizhen What you described seems to be what the doc says:

    https://docsify.js.org/#/configuration?id=relativepath

    Can you make a reproduction?

    The current implementation only consider a single base path for relative paths.
    My point is that when there are 2 md files loaded, one sidebar, and one content md, the relative paths in the sidebar md and the content may need different base paths:
    relative path in the sidebar md should always base on the sidebar md path; the relative path in the the content md should always base on the content md path.

  3. ruanqizhen commented on Dec 7, 2021

    @ruanqizhen
    Author

    Just use the case in the document:

    .
    └── docs
        ├── README.md
        ├── guide.md
        └── zh-cn
            ├── README.md
            ├── guide.md
            └── config
                └── example.md
    

    Suppose there is a single sidebar file for all the md files listed here, with the current relative path mechanism, there is not way to make the links in sidebar point to the right files.

  4. ruanqizhen commented on Dec 8, 2021

    @ruanqizhen
    Author

    Found a workaround: I'm using absolute path in sidebar file, and using relative paths in other files now.

  5. trusktr commented on Dec 8, 2021

    @trusktr
    Member

    I see what you're saying: yeah, links in sidebar should be relative to the sidebar file. That would be most intuitive.

    When this is implemented, we need to think if it needs to be behind an option so as not to break existing apps.

  6. reopened this on Dec 8, 2021
  7. changed the title [-]The relativePath mechanism is very confusing[/-] [+]relative paths of links in sidebar should be relative to the sidebar file[/+] on Dec 8, 2021
  8. mike-potter commented on Jan 11, 2022

    @mike-potter

    I am also very interested in this functionality. In my use case I have a top-level "portal" docsify site that brings in several other project docsify sites as subfolders. Each of the projects has their own _sidebar. But when used in the portal, the links in the project sidebars no longer work because it's using the main top-level folder instead of looking relative to the folder containing the sidebar.

  9. mike-potter commented on Jan 11, 2022

    @mike-potter

    It's possible that using relativePath: true helps with this, if all of the sub-projects are also configured for this.

  10. mike-potter commented on Jan 11, 2022

    @mike-potter

    Nope, that doesn't work either. If the projects have subfolders, then once a page in the subfolder is loaded, the other pages in the sidebar no longer work as they use the new subfolder as the relative path. So still can't find a way to basically embed one docsify site within another.

    I agree with the OP that the links in the sidebar should be relative to the location of the _sidebar file. Using relativePath just makes them relative to the current path, which changes once you are in a subfolder.

  11. trusktr commented on Jan 12, 2022

    @trusktr
    Member

    Yeah, it's a bit counterintuitive right now.

    For backwards compat, I believe we need a new option for this (false by default). It will override relativePath for the sidebar.

    Perhaps named like sidebarLinksRelativeToSidebarFile? Any other naming ideas?

    The docs need more clarity here too.

  12. trusktr commented on Jan 12, 2022

    @trusktr
    Member

    Closed #1139 in favor of this one.

    cc @CxRes (since you were interested in trying to solve it with that code mod you made in the other issue, open to a PR)

  13. hexus commented on Jan 12, 2022

    @hexus

    How about relativeSidebarPaths?

  14. hamishwillee commented on Aug 24, 2022

    @hamishwillee

    Is there any approximate ETA on this or plugin that could be tried to get the functionality in the meantime?

    This will make multi-lingual and multi version libraries very much easier to create, and remove the limitations where you're forced to have your content for translations in different repositories.

    Or to put it another way, I have my docs structured like this.

    /en/*
    /zh/*
    

    And I have different versions stored as branches in same repo. I want to access the paths using aliases.
    e.g. main/en/*.*, v12/zh/*.*

    If the sidebar links were relative to the sidebar then this would work for versions, translations, whatever, because the context would be relative to the imported root.

    As it is this can't work unless every summary has the full language and version path specified absolutely. Yuck.

  15. hamishwillee commented on Feb 12, 2023

    @hamishwillee
  16. jhildenbiddle commented on Mar 2, 2024

    @jhildenbiddle
    Member

    Bug acknowledged. Tracking with #1891.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions