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.
Hope you like it!
This is amazing, I wanted a field like that for such a long time. And I’ve seen a lot of posts in this forum that asked for something like that.
I think this will be in a lot of future Kirby projects!
This indeed will be very handy. Thanks !
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
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)
Ok, but then deletions aren’t handled by using autoID afaik.
It’s a hard nut to crack. I’ve been on the lookout for something like this to have taxonomy of some kind in kirby.
No, but deletions are pretty easy to handle in your template loop.
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.
If you would add these “apple”, “pear”, “strawberry” categories as pages and then check if they still exist in your template you won’t have a problem.
<?php if($category = page($category)): ?>
// Category page still exists
<?php endif ?>
(Very simplified example, you would probably have a category container page)
In a multi-lingual scenario, you would have to add some sort of mapping between page and category, but all doable.
But as I said above, you could also use a hook that removes those categories from fields once a category page get’s deleted.
@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.
BTW: The plugin is inspired by this excellent field for Advanced Custom Fields (WordPress): https://www.advancedcustomfields.com/resources/relationship/
Does it need a particular kirby version to work ?
Toolkit version: 2.5.1
Kirby version: 2.5.1
Panel version: 2.5.1
And with the default example:
it does not render well:
Do the assets get loaded? Have a look in your browser console…
Hmmm, now it is working, possibly a permissions problem, thanks!
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.
I made a little plugin for a “bidirectional edit”, might be interesting for this discussion: