I have just released a new Kirby plugin: Relationship – a sortable multiselect field.
It’s an extension of the native checkboxes field, so you can just replace all instances of the Checkboxes field with this field in your blueprints to get your items sortable. The data is saved in the same way as the Checkboxes field, so it’s interchangeable out of the box.
It’s not really a “relationship” imho.
E.g.: what happens if I draw in pages in the options to link to, but after a while a linked page is moved, deleted or is given a new URL (id)? Now my previously linked pages have “wrong” or “unexisting” links in this field. How does it handle that case?
It’s not any different than a checkboxes or select field in this regard.
You can decide yourself if you want to use the uid as the saved variable or use something like the AutoID Plugin in the query.
Like with all links to images or pages - no matter what kind of fields you use, you would have to check in your templates if it still exists (unless you use the AutoID plugin, that is).
Otherwise you would have to use complex logic to keep track of all your links (e.g. using hooks)
What if I create a list of options “categories” with values “apple”, “pear”, “strawberry” and I tag a few pages with each term.
Each page template uses the value of “categories” to create a link to another page where we have an overview of all linked content. E.g. a page tagged with “strawberry” has a link to an overview page where we aggregate all “strawberry”-tagged content.
What happens if we suddenly decide to “delete” strawberry? We can remove it from our options, but there remain a whole bunch of pages tagged with strawberry which will all generate that link to an overview we no longer want to exist.
And consider this in a multilingual scenario, it makes it even more difficult.
@bvdputte Regarding the name, you are sort of correct. It’s not a true relationship plugin, where selected pages updates automatically with a link back to current page (if I understand you correct). It’s not bi-directional.
But, in a sense, the name Relationship can be applied to this field. Why? Because you can select pages that belong to each other, related pages. And because the options are sortable, you can sort pages depending to how they relate to each other.
But I understand your question regarding if this is a true relationship field. A true relationship field should be bi-directional. In fact, for a large site I’m building, I have actually made a plugin that is bi-directional. It works like this: I have a field where I can select another page. The page I choose, will be automatically updated with a link back to the original page. If I later remove the link, the other page will automatically be updated with the back link removed. This plugin is kind of custom built for this specific site, but it should be doable to package it into a generic plugin for any site.
One of the future features I’m thinking to implement to this Relationship plugin is this bi-directional behavior. Time will tell if I succeed.
countries:
label: Countries
type: relationship
options:
sweden: Sweden
norway: Norway
denmark: Denmark
finland: Finland
iceland: Iceland
germany: Germany
france: France
spain: Spain
portugal: Portugal
I just published a brand new version of this plugin. It’s rewritten from scratch with accessibility improvements in mind. You can now navigate the plugin with your keyboard, and screen readers should understand the plugin better. There is also support for thumbnails, which was a frequent requested feature.