Sorting in panel after dragging images (markdown set in config) causes invalid links

[shoesforindustry]

Using Markdown (set in config) c::set('markdown.extra', true);

If I drag an image I get: ![some text](http://mydomain.net/content/1-projects/3-items/2-section/image.jpg)

Which is fine unless I sort any of the projects/items/section pages, then all the links are incorrect!

Is this right? It does not seem to do this when the site is set to use Kirbytext?

If it is not a bug, then some way of disabling the sorting in the panel and automatically adding the next number to a new projects/items/section (in my case), otherwise, with a simple drag and drop, all your links are invalid!

I know I was that boy...

[lukasbestle]

I can't reproduce this. I still get (image: image.jpg) if I enable Markdown Extra.

[shoesforindustry]

Sorry Lukas, I think you probably have to also set c::set('panel.kirbytext', false); in your config.

I just tried this on a new Kirby download, with just this in the config c::set('panel.kirbytext', false); `c::set('markdown.extra', true);``

[shoesforindustry]

To try and make it clear, dragged to a page with above settings:

Dragged: ![about](http://kirby.dev/content/1-about/about.jpg)

Entered Manaully: (image: about.jpg)

Results: <p><img src="http://kirby.dev/content/1-about/about.jpg" alt="about" /></p> <figure><img src="http://kirby.dev/content/1-about/about.jpg" alt="about"></figure>

Move the page in Panel: <p><img src="http://kirby.dev/content/1-about/about.jpg" alt="about" /></p> <figure><img src="http://kirby.dev/content/3-about/about.jpg" alt="about"></figure>

The markdown one (first) remains the same and is wrong, the second (kibytext one) changes which is correct.

[texnixe]

This behavior is not surprising, because the markdown link - once dragged into the field - contains a fixed link while the link from the kirbytext tag is generated at render time.

[shoesforindustry]

OK texnixe, thank you, I was afraid that was the case. So are we really saying that dragging images with Markdown does not really work in any real practical sense? Unless you can somehow stop the sorting of all pages/parent pages?

[lukasbestle]

Markdown also accepts relative file paths (like ![about](about.jpg)), but the output of this code will be an img tag with a relative path as well. It happens to work because of the internal file rewriting rules in Kirby, but in the background this requires a redirect to the actual URL.

So Kirby can choose between two trade-offs: Either use relative paths and rely on the redirection or use absolute paths and break when changing the hostname of the server or the sorting of the pages. The solution that didn't require a trade-off for this was, well, Kirbytext.

Is there any reason why you need to disable Kirbytext? I think that the syntax is way easier to understand and can be extended with your own tags, which isn't possible with raw Markdown.

[shoesforindustry]

Lots & Lots of pages in markdown ;-) It is what we write in. Relative paths maybe the best answer unless someone can think of something else?

[lukasbestle]

You can still use the Markdown syntax even if you also use Kirbytext. Kirbytext is just an extension for Markdown. The panel.kirbytext actually only changes the link and image syntax that gets generated in the Panel, it doesn't "disable" Kirbytext or "enable" Markdown.

[texnixe]

If you don't disable panel.kirbytext, however, you don't get markdown style links by dragging and dropping an image, but an image kirbytag. You would have to add the links manually. I tested adding relative markdown links, but that does not seem to work?

[lukasbestle]

The relative file links only work when the URL of the page ends with a slash. By default they do not, so the browser tries to request the wrong file.

[shoesforindustry]

Nothing wrong with Kirbytext, but we don't need another version of Markdown ;-) We have lots of image Markdown in markdown files already and I was looking forward to drag and drop for new files as we move to the Panel editor rather than an external one. I too thought relative images would work, as that is what we use currently with external editors, but the relative image problem is a bit unexpected and quite annoying. Mmmm... what todo?

[lukasbestle]

So what do your current Markdown image links look like?

[shoesforindustry]

lukas, it depends what we are using, but outside of Kirby relative links, the normal markdown: ![Some blurb](images/image.png)

[lukasbestle]

Outside of Kirby, yes. :smiley:

I'm afraid there isn't really anything Kirby could do about this without breaking compatibility with the Markdown standard. Hijacking the relative links to make them absolute isn't really the solution.

[shoesforindustry]

How about letting the dragging of 'markdown' links become relative and then remove the need for the back slash at the end of the URL? Seems like a pretty good alternative to me? What are the downsides?

[lukasbestle]

The problem is that relative URLs won't work, because then it's the browser's task to resolve the relative path.

Since Kirby page URLs don't contain a trailing slash by default (though adding it manually works), the browser won't be able to resolve the URLs. One way to fix this is by adding the page UID at the start of the relative path so that the browser can resolve the URL correctly (unless the user adds a slash at the end of the page URL, which will break it again). Also this will require a redirection when the browser requests the image file (since it won't request the file directly in the content directory but using the page URL).

The "real" solution would be to dynamically change the URLs to be absolute so that the browser doesn't need to do any resolving work. But as I wrote that's not possible without breaking compatibility with Markdown.

Actually it seems like you are the first (or at least one of the first few) to have this issue. Without ignoring your bug report and the issue at all: Wouldn't it be easier to use Kirbytext after all, be it only for image links? As I wrote, you can still use the rest of the Markdown syntax together with Kirbytext.

[distantnative]

Is this still an issue? It seems to me that there won't be any fix for the underlying issue but that a mix of Markdown and Kirbytext can solve the problem fairly easily. So I would suggest closing this issue if none of you (the involved discussants) disagrees.

[lukasbestle]

I agree. As I wrote, Kirbytext is the preferred solution for this. Markdown has its disadvantages and that's why this is an optional setting.