Page linking with less typing

1

Hello, I started testing Grav and really love it. I’m thinking of migrating my Dokuwiki site to Grav. Since Grav uses Markdown, it’s more typing when linking pages. For example, in Dokuwiki
[[Hello World!]]
will normalize the page name, link it to “hello_world” and display “Hello World!”. However, in Grav,
[Hello World!] (/hello-world)
I have to type the page name twice in different formats.

The most ideal solution would be a new link syntax that does this conversion. It’s both text-editor and admin-UI compatible. e.g., [[…/Hello World!]] syntax that converts it to [Hello World] (…/hello-world) internally or something similar?

Another less preferred admin-UI-only option would be a plugin that can list all page names and allow inserting a page link with a single click (H1 header as page name). This is something similar to the link icon in the Discourse text editor here but with a list of pages.

Thank you!

2

I wrote this plugin to support MediaWiki-like syntax. Demo at https://demo.isnew.info/grav/markdown-yalinker

3

This is a nice plugin!

Grav tries to stay as close to the official Markdown syntax as possible. Markdown which contains “YALinks” is less portable since the links will only render into working HTML links when your plugin is present. This may not be bad but is something users should consider before using these “YALinks”.

I have been thinking about Grav versus Wiki’s and like a potential mix. In a Wiki a link to a non existing page is shown in red. If one clicks it the user is invited to create that page.

Now there’s a plugin called Add Page by Form which allows frontend users to create a new page. This plugin could be extended by acting upon the onPageNotFound event hook. So when a (looked in) user goes to a page which does to exist he or she does not get the normal 404 error page but is shown a form to create that page.

Would that be useful? What do you think?

4

I agree with you that potential users of this syntax plugin have to think about the pros and cons of this plugin before enabling it. I think any plugins that change the syntax have the same concern.

As for the wiki-like behavior, I think that’s a good idea. The only thing is I would create a new plugin that does NOT change the syntax. This way, users will have more options.

BTW, is it possible to rewrite text when saving it to Markdown files? For example, I could implement an option in the YALinker plugin that allows rewriting YALinks into regular Markdown links right before saving the file. You’ll lose YALinks, but you keep full compatibility with Markdown. But, not from your favorite editors :-(.

5

In response to your “by the way”-question, yes that’s possible.

You need your plugin to subscribe to the onPageInitialized event. Then is the corresponding function do roughly this:

$page = $this->grav['page'];
$content = $page->rawMarkdown();
// Modify the content here
$page->rawMarkdown($content);
$page->save();
6

Thanks! Now, I’m thinking about this feature… It would be difficult to cleanly convert YALinks to Markdown links because of preformatted blocks such as code. Simply converting any [[...]] occurrences into Markdown links will break those blocks. I think the only way to achieve this is to run the Markdown parser and convert [[...]] to Markdown links. This way, we can ensure that YALinks inside preformatted blocks won’t be converted.

7

I’m not sure if I can implement this Write Markdown links feature reliably without almost reimplementing a Markdown parser at least for inline/block code syntax to avoid rewriting YALinks in preformatted text. Right now, this experimental version supports code blocks. Inline code is tricky because Markdown supports inline code across multiple lines. Not only that, an empty line breaks it.

`[[inline]]
continues
[[inline]]`

`[[inline]]
NOT

[[inline]]`

outputs

[[inline]] continues [[inline]]

`[[inline]]
NOT

[[inline]]`