Ok so I have found a couple of ways around this. None are optimal but can work.
First approach is to create a repeatable component that takes 1 relation to a collection. You can then reorder this component to whatever suits. The problem with this is that you often run into problems with deep nesting.
Using graphQL seems to help prevent some issues with deep nesting.
Second is if you delete all items in the relation field, and add them back in again in the correct order, it should maintain the order. However this means if you want to add a new one in the second position, you need to delete all items from the list, and add them back in again. This is also just kinda flaky.
Lastly you can add a field to sort by. I actually haven’t tested this, as at that point I usually query & filter the whole collection type, rather than using the relationship field.
Hope this helps someone, but I agree it would be really convenient to be able to reorder a multi relationship field.
The ability to change the order of items is essentially for users.
As a developer, you can find a lot of workarounds i.e. adding custom fields, plugins, deleting and reinserting items …etc.
But the user needs to be able to just drag and drop the item up or down to get a new order of items.
That’s not depends on headless or monolith architecture of CMS.
If it’s CMS and end-user works with it directly, it should respect User Experience (not developer).
Actually, easy reordering of items (especially media) through the admin GUI is a key feature in case of choosing CMS for new project.
We have recently implemented our new site using Strapi - a fairly typical SaaS type site where we feature use cases and clients and we want to be able to manually determine the order that use cases are presented at various places in the site, to reflect those that are most valuable within the context.
The developer who built the Strapi implementation used relations - make sense we have use case entities and we have pages where they need to appear and there is a many to one relation.
Then as the thread above reflects, there is no way for content creators to order these use cases other than manually deleting them all and then readding them in the target sequence, which when you’ve got a dozen or more entities is crazy tedious when even the most of UX would just allow someone to drag them into order.
I think it’s extremely arrogant to assume that this is not a core use case for a CMS when weighting relationships is a common requirement. At the moment I feel as though we made a bad decision to go with Strapi.
PS: Lack of 2FA or any brute force protection on admin logins was an unpleasant shock but that’s a whole other story.
Strapi v4.5 (currently in beta) will lay the foundation for sortable relations. From my interpretation even though v4.5 will not support sortable relations, it enables the core Strapi devs to work on that for a possible v4.6 release.
Last I spoke with the product manager for our content squad (the squad working on the relations stuff), I think we actually will get order-able relations in v4.5, -I think-
