Improving the Multiselect Field Serialization Format

Kirby 3 Suggestions💡
1

I often find myself alternating between the multiselect field and the pages selection field.
Usually I’ll throw the multiselect field in when I want the user to pick a small number of pages. Then I may change it to the pages field if it turns out the users are actually selecting a lot of things since the UI for the pages field is better for displaying lots of selections. Or vice versa, downgrade to the multiselect field because it’s UI is lighter for one or two selections and it’s faster to pick things with than the pages field is. (Especially with the search feature.)

The downside is that the pages field and the multiselect field store their data differently.

Multiselect:

Person: people/jason, people/ashley

Pages:

Person:

- people/jason
- people/ashley

This makes switching between them more difficult than I think it needs to be. Right now I have to go and update all of the content pages for the template I’m changing. If they used the same format for serialization, or each could read either format, than swapping one out for the other would be as easy as changing pages to multiselect.

Similarly, calling ->toPages() on the pages field just works while calling it on a multiselect looks like ->toPages(','). Which means the template must also change (unnecessarily in my opinion) when switching fields in the blueprint.

I think that since the multiselect field is specifically for selecting multiple things, it should store those things in a regular array the same way that the pages field does, rather than in a “something delimited string.”

Thoughts?

2

How about creating an issue in the ideas repo?

3

Sure. Is the forum not a good place to discuss things like this?

4

Of course it is. But if you want to bring this to the attention of the devs, the ideas repo is a better place.

Your idea actually makes sense, and it probably would for checkboxes as well. And I think it could then read the old comma separated list and convert it when storing so that fields that use the current storage format would still be compatible.

5