Link to page/file in writer field (picker UI)#268

The possibility for internal links (= link to another page) would be nice for the writer field.

I’m thinking about it. Since the writer field does not work like markdown, when we add the link of the page, it will save the absolute link that includes full url as HTML like http://example.com/some/page, not the dynamic link like (link: some/page). Do you think this is a problem?

Either way would be an issue, imagine if your page change slug, the link will then be broken. That’s why it’s necessary to have immutable id’s for internal linking.

Since we do not have an immutable id at the moment, also problems may occur in the links we give with the link() tag in markdown. The point I want to draw attention to here is the domain address. When we first make the site on localhost and then move it to the prod domain, links with localhost will not work. Is this an acceptable case?

At the moment this is our workaround: We add a base url and use the page slug of the target page in the link input.

I don’t think the domain should be stored

Do you think the links should be stored like this?

<a href="/some/page">Link to page</a>

<a href="/subfolder-kirby-installation/some/page">Link to page</a>

It would be best if there was a special mark for such an internal link so that the correct link tag can then be constructed in the backend when the field is rendered. However I don’t have a good overview over the writer field at the moment to tell if it’s possible and how this would be done.

Now that we have permalinks I really hope we can get this into the core because as others have mentioned it is a bit of a pain in the ass to manually copy/paste page links, especially for clients.

Now that we have permalinks, page links should be stored like this (I think option 1 is better);

<a href="page://Eesj89FnbMzMMvs0">Other Page</a> // [1]
<a href="https://yoursite.com/@/page/Eesj89FnbMzMMvs0">Other Page</a> // [2]

However, for the frontend, I think the output should look like this:

<a href="https://yoursite.com/lorem/ipsum/other-page">Other Page</a>

This means that the text stored in the .txt files will have to be converted somehow, which could be a bit difficult and will also be a small performance drawback.

I agree, the introduction of UUIDs has made this more relevant than ever.

I once again had to explain a customer how to link files with the writer field:

1. upload file
2. click on file
3. click on url
4. copy url
5. select text
6. click on link icon
7. paste in url
8. wash hands because you linked an internal file using an absolute url

While it could be:

1. select text
2. click on attachment icon
3. upload file

Encore
The user replaced the file.

..drumroll..

And the link breaks.

Because: the copyd url contains a hash that (correctly) changes with the file.

@Tobias.f.wolf‘s concept where permalink page/file urls resolve to long urls at render time looks like a great idea.

It would be really helpful, if we could paste a permalink to a page or file in the url field like
page://wwZfUaAonRARD3oL?param1=val1&param2=val2#footer or file://MiS3i2Nc5wtVFltK.
It also wouldn’t be to hard to explain it to any panel user how internal linking works.
Right now it’s not possible to prepare some content on the dev server because the domain won’t be right, when the site goes online.