Diagram path computation resolves incorrectly

[manueleiria]

The issue we're having has been pinpointed.
Consider the following folder structure:

docs/
-> folder/
  -> file.md
  -> diagram.md
-> index.md

Essentially, when declaring a diagram such as ![diagram](diagram.drawio) in file document.md, the mkdocs-drawio-exporter is able to generate it correctly, but when placing it after generation the file structure looks like this:

docs/
-> folder/
  -> file.md
  -> diagram.drawio
-> index.md
site/
-> folder/
  -> file/
    -> index.html
  -> diagram.drawio-0.svg
-> index.html

At this point the diagram is no longer in the same directory as the html page and the diagram can't be found. Of course, if I change the src in the developer console to ../diagram.drawio-0.svg it then finds it without issue. Since our mkdocs generates pages this way, is there a possibility do add a rewrite as parameter perhaps?

[LukeCarrier]

This might be the issue described in #83; I'll try and take a look when I get chance. In the meantime if you could prepare a minimum repro case that would really help speed things up. You could modify the example setup in the docs if that helps.

[manueleiria]

That seems like a different issue where their own navigation isn't working as intended. We have closed source in our repo for the templates, so it might take some more time to get you a test repo. The behaviour happening however is that mkdocs turns all navigation that is not an index page the following way:

index.md
navigation1/
->diagram.drawio
->index.md
->other_page.md

into:

index.html
navigation1/
->diagram.drawio-0.svg
->index.html
->other_page/
  ->index.html

Let's say that both navigation1/index.md and navigation1/other_page.md both reference the diagram as ![diag](diagram.drawio#0).
This will mean that navigation1/index.html will be able to reach the diagram, but not navigation1/other_page/index.html. In this case there will need to be a rewrite happening to point the navigation to the correct file. I will try to provide a better test example after the weekend.

[LukeCarrier]

In the absence of a repro case, can you try and repro the issue on 0.9.1? There were changes in 0.10 to the hooks used to rewrite links that were intended to improve compatibility with other plugins which might explain both behaviours.

[manueleiria]

It's my belief that in 0.9.1 we didn't have this issue. I will have to verify some cases to be absolutely sure, but when we regressed the issue didn't happen.

…

On Sat, Jan 25, 2025, 17:42 Luke Carrier ***@***.***> wrote: In the absence of a repro case, can you try and repro the issue on 0.9.1? There were changes in 0.10 to the hooks used to rewrite links that were intended to improve compatibility with other plugins which might explain both behaviours. — Reply to this email directly, view it on GitHub <#87 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKNPIZ3IQOJ3F5FT2YCQT2MPEJ3AVCNFSM6AAAAABV2CNNT2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJUGA2DGMRVGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>