Parsing Wikipedia Links in Markdown

The CMS Questions
1

I’ve been pasting in URLs into the panel for article text and making sure they are converted from HTML into Markdown.
Example:
https://en.wikipedia.org/wiki/Typhoon_Haiyan_(2013)
Sometimes the URLs for a link contain a closing parens and this results in the (link: improperly closing after the parens.
Any thoughts on this? I’ve created an issue for the wonderful Kirby Markdown plugin which I’m using but it’s possible the problem also exists outside of the plugin. Parsing Wikipedia links · Issue #79 · fabianmichael/kirby-markdown-field · GitHub
My workaround is to simply use standard HTML instead of Markdown for these occasions.

Has anyone else had this issue?

2

You can urlencode the parens:

(link: https://en.wikipedia.org/wiki/Typhoon_Haiyan_%282013%29 text: Typhoon Haiyan)

or use markdown links

[Typhoon Haiyan](https://en.wikipedia.org/wiki/Typhoon_Haiyan_(2013))
1 Like
3

Well, that’s true, and that’s an easy solution. But however rare this issue is, it would break for the client since they would likely not know why this is happening.

4

Its worth pointing out that that article gets redirected to https://en.wikipedia.org/wiki/Typhoon_Haiyan … to much to ask that they use that link instead?

1 Like
5

Thanks, @jimbobrjames.
Well, that’s a wonderful point, actually. Best practices of URL syntax and all that.
We can just tuck this issue under the rug now.

1 Like
6

No worries. I think wikipedia mostly uses the parenthesis on the end for the purposes of disambiguation. If they use the real, redirected link, all should be fine.

1 Like
7

But look at https://en.wikipedia.org/wiki/Typhoon_Haiyan_(disambiguation):

If you want to link to https://en.wikipedia.org/wiki/Typhoon_Haiyan_(2001) you cannot use https://en.wikipedia.org/wiki/Typhoon_Haiyan.

8

This is a big issue, imho. Clients will want to use parens in the link text, too. I would love to use standard markdown links, but is it possible to reprogram the link button in the WYSIWYG editor to do that, too?

9

What do you mean?

Currently not, but custom buttons for the textarea field. are on the roadmap, I think. Or you can create a custom version of the field.

10

I guess you could use a URL shortening service, which would a cleaner URL to use.

11

I shouldn’t have said WYSIWYG editor, but when buttons are enabled.

12

That does not help when you have the parens in the link text:

(link: https://example.com/ text: Find more information (about the issue) at example.com)

It’s a slightly bad example, but it is realistic to find it in client texts. This would output:

<a href="https://example.com/">Find more information (about the issue</a> at example.com)

instead of the expected outcome:

<a href="https://example.com/">Find more information (about the issue) at example.com</a>

I tried quotes, but they are just output as raw quotes:

(link: https://example.com/ text: "Find more information (about the issue) at example.com")
13

@yatil Yes, those cases are not easy to handle, there are certainly workarounds, e.g. let users use square brackets and replace with a kirbytext hook afterwards etc. But that requires educating users, of course.

14

Yeah, it is a bit annoying as it is a regression from standard markdown, which handles both cases gracefully. Workable, but maybe it would be nice if we could improve it somehow :smiley:

15

When I put my Twitter plugin together, i needed a way to turn links into clickable links, since the Twitter comes back with tags stripped. Theres a function in that plugin, i forget where i found it. The reason i bring it up is that it wouldn’t take much to borrow that function and turn it into a field method.

That way you just paste the url straight in the field without using the Kirby tag, and the field method will link it up. As for link text, im not sure how you would handle that, you would need to expand the function a little.

16

You can disable kirbytags in the Panel in your config.

    'panel' => [
      'kirbytext' => false
    ],

Kirby will then insert standard markdown syntax instead of Kirbytags.

You will lose the additional options you can use with Kirby’s link or image tags (adding classes, captions etc.). So while yes, tags are in a way a regression compared to standard markdown, they also have a lot of advantages.

17

You can do that anyway and markdown/kirbytext will parse it without any additional functions. But the problem here is the link text, or the combination of link + link text + additional attributes like classes etc.

18

I guess what is really needed here is a way to change the charachters that kirby uses to detect the tags, so you can do [link: ..] or something, but i bet sooner or later that will upset some other kind of link for something else. You would have to pick a charachter that wasnt legal in a URL.

19

Exactly. I can’t find it now, but we had this discussion already back in Kirby 2 or even Kirby 1, trying to find a pattern that would allows parentheses, but it never lead to anything.

Additionally, there’s the problem with backwards compatibility…

IMO, the easiest way to solve this is by asking users to use square brackets instead of parentheses if they absolutely need to use them in Kirbytags, then replace with a filter. Or, if you can do without the additional features offered by tags, disable Kirbytags in the config and use standard markdown instead.

BTW: There is already an ideas issue on GitHub: Support round brackets in KirbyTags · Issue #10 · getkirby/ideas · GitHub

1 Like
20

What if the new way that kirbytext understands a link is by determining if it has an open parens in the link, and automagically understanding that there might be a closing parens, too? And then behind the scenes encoding it as such. This would bypass this rare (but painful) issue of educating clients.

Until then, it’s not the end of the world for this problem to exist, and it is, indeed, an edge case. Thanks everyone.

1 Like