How should plugins handle the link dialog with UUIDs?

Resources Plugins
1

I’ve been working on fixing an issue in the markdown field for a few weeks now, and I would greatly appreciate some input from the Kirby team. Allow me to explain the issue with links to the relevant code parts:

The Writer and Textarea fields both use the link dialog. While the writer leaves the submit method untouched, the textarea overwrites it. In the default submit method there’s a .replace() happening, turning file:// into /@/file/ and page:// into /@/page. If I understand it correctly, this happens so the Writer can have permalinks instead of the UUID protocol links.

However, because this happens in the link dialog instead of the Writer field, every plugin using this dialog automatically gets the permalink URLs instead of the UUIDs. It feels wrong, but for now I just replace it back, turning /@/file/ into file:// and /@/page into page:// again.

To me this seems a bit fragile so I’d like to discuss this with the Kirby team. How do you expect plugins to handle this? Thank you!

1 Like
2

This issue I tried to fix in the Markdown field followed me to a new project. I’d really appreciate some input how to deal with UUIDs and the link dialog in plugins.

If this is just how it works, I can live with that too! Promised! I just want to make sure I’m not missing something, leading to potential breaking-changes in the future.

3

Ping @distantnative

4

@thguenther I guess what you are saying is that the writer field should have its own link dialog (extending the default link dialog) where it does this kirby/panel/src/components/Dialogs/LinkDialog.vue at c1e6ff77b056774543f201035f5dab6a02bfdb3b · getkirby/kirby · GitHub replacing - so that the basic link dialog is left with the UUID values?

The textarea dialog would still also need its own version to turn it into markdown/kirbytext: kirby/panel/src/components/Forms/Toolbar/LinkDialog.vue at c1e6ff77b056774543f201035f5dab6a02bfdb3b · getkirby/kirby · GitHub

5

Thanks for the reply, @distantnative!

Anything that makes the link dialog usable for plugins is fine to me. It took me an embarrassingly long time to understand what’s going on, so I don’t want to make any suggestions myself. Having a reusable “base” link dialog sounds good, though.

If it doesn’t make sense to use the link dialog component at all, that’s also fine to me.

6

Will have to look if we can change this in v4 or v5.

I think a stable solution for you could also be the create a custom link dialog that extends the default link dialog, but overwrites the submit method with something like

submit() {
	this.$emit("submit", {
		...this.values,
		target: this.values.target ? "_blank" : null
	});
}

(or whatever format you need to consume it in your field)