Filename links are treated as relative links on random

[Andre601]

I encountered a weird behaviour, where the plugin doesn't seem to handle filename links at random, which causes them to turn into default relative links.

My folder structure (relative to the docs folder) is as follows:

- assets/
   +- css/ // CSS stuff
   +- img/ // Images
   +- icons/ // Custom SVG Icons
- index.md
- github/
   +- general.md
   +- issues-pull-requests.md
   +- wiki.md

The issue appeared in issues-pull-requests.md when I tried to link to general.md using

[:brands-github: General](general){: .md-button }

The link was rendered literally, meaning the resulting link, relative to the page, was issues-pull-requests/general

What makes it more confusing is, that I use the same link ([general features](general)) on a different part in the same file and the resulting link actually points to the page in question.

Here's the part of my file, where it happens:

!!! pages "Pages"
    [:brands-github: General](general){: .md-button }

# Issues/Pull Requests
This page lists all features that can be used across all issues and Pull requests on GitHub.

!!! info "Note"
    Issues and Pull requests support all [general features](general).

The part inside the Pages admonition, which is a custom admonition type I set up, is not working, while the link in the info admonition is.

I have a guess what could be a possible cause. This started happening, when I changed the Link to a file from a total https-link to a basic filename link. Perhaps the Plugin became somewhat confused and didn't handle the first link right. Or maybe a cause could be reference links? Although I doubt this as I didn't encounter this issue anywhere else, where I also use those reference links...

[orbikm]

I am currently unable to reproduce your issue. When I enter in either admonition, the link scanner correctly navigated my test site from one link to the other.

I'm curious to know more about your operating environment. For instance, how are you testing this? mkdocs serve, mkdocs build and then deployed, etc.?

It might also be helpful to see your mkdocs.yml, at least the relevant portions.

Also, maybe any relevant logging that is output with the '-v' flag passed to mkdocs. I might be able to spot something funky in the logs.

[Andre601]

I used mkdocs serve and the env was a Windows 10 Pro PC with Python 3.7, MkDocs 1.1, Material for MkDocs 7.0.4 and PyMdown.

The currently used mkdocs.yml file can be found here: https://github.com/Andre601/GitHub-Markdown/blob/master/mkdocs.yml

[orbikm]

Ok, thanks for the quick response. I was able to reproduce the issue locally. I had to clone your repo & test using that in order to actually hit the issue.

As far as I can tell (in my quick testing tonight), the only links that are not working are located inside of the _snippet nav segments. Those links exhibit the behavior that you stated. When I remove the '.md' from the link inside that snippet, it no longer functions.

Turns out, EzLinks never scanned any of the links in the snippets. This is due to my plugin receiving literally the --8<-- filename, not the actual contents of the file.

I will look into it further tomorrow. I may be able to modify EzLinks to be compatible with the markdown snippet extension.

[Andre601]

This also happens without snippets. Like copy the content of the snippet into the corresponding page and it should happen too

[orbikm]

Interesting. I can repro this now. I think I understand what's going on. I think the md_link_scanner regex is not capturing those links correctly. Therefore, EzLinks doesn't even scan it at all (I believe). Now, if you have '.md' in the filename, the link works, but only (I believe) because it's a file that mkdocs can find, at the same directory level, so it works just like a normal mkdocs md link (relative to .).

If you remove the .md, I believe the behavior matches for when a normal mkdocs md link can't find the file in question, it treats it as a direct link, and causes the whole issue-pull-request/issue-pull-request snafu.

Anyways, I'll look into this this evening (few hours), and hopefully have a fix I can release by this evening. I'll keep you posted, and thank you so much for your responsiveness here. I am gonna do my best to ensure the first users of this plugin have as good of an experience as possible, while we round out the rough edges like this!

[orbikm]

Ok. So I think I finally squished this bug. So, we were both correct: The EZLinks plugin can not scan inside markdown extension snippet segments. This is because the plugin gets the actual raw --8<-- text, meaning we process the markdown prior to any expansion that is down by any markdown extensions.

On top of that, there was also a bug in my RegEx that prevented the link scanner from working on multiple links on a single line. I have fixed that, and will be submitting a fix & releasing ezlinks 0.1.8 to address this failure.

Now, as for what you may want to do in order to fix this. Given the way that mkdocs works, I do not believe we have the chance to do any markdown processing post markdown extension. So if you want to have EZLinks be included into your pages by including a file, I would suggest you use the mkdocs-macros-plugin, along with the {% include 'filename.txt' %} syntax.

The reason this works as an alternative is that it is also a mkdocs plugin. This means, as long as you declare the macros plugin above the ezlinks plugin in your mkdocs (see below), the EZLinks will then be scanned after the inlude has already executed.

plugins:
  - search
  - macros:
      include_dir: '_snippets'
  - ezlinks

I will close this issue once the fix is merged.

[orbikm]

The fix is live and included in the published 0.1.8 release. Please let me know if you continue to experience this issue, we can always reopen it, and thank you for using my plugin!

[Andre601]

I coincidentally enough just checked Material for MkDocs' page about using the makros plugin today xD