Sorry, we don't support your browser.  Install a modern browser

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.

2 years ago

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, not the dynamic link like (link: some/page). Do you think this is a problem?

2 years ago

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.

2 years ago

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?

2 years ago

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.

2 years ago

I don’t think the domain should be stored

2 years ago

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>
2 years ago

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.

2 years ago
Merged Link to file in writer field#215
a year ago
Changed the title from "Link to page in writer field" to "Link to page/file in writer field (picker UI)"
a year ago

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.

a year ago

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="">Other Page</a> // [2]

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

<a href="">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.

9 months ago

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

8 months ago

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

The user replaced the file.


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.

8 months ago

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.

7 months ago
Changed the status to
In upcoming releases
4 months ago