[5.x]: Multi-select fields not respecting their order of the options but are outputting by order they are picked which differs from the order shown in the back-end system

[terryupton]

What happened?

Description

When using a multi-select field (https://craftcms.com/docs/5.x/reference/field-types/multi-select.html) the back-end system adheres to the order the items are listed on the options within the field. If you pick these out of order, upon save they get re-sorted into the correct order.
However, on the front-end when looping the field and the selected options, the order is presented in the order that the editor picked them.

Would it be possible to ensure that the order matches the back-end and is ordered by the native order of the list options.
I am not sure if this is a bug, but I believe this was working correctly when I first set up these fields and tested them.

I can see arguments for both cases, so perhaps a flag or option we can pass into our twig templates to order by the field options rather than the picked options. Even then though, he CMS shows them in the order of the field options, so it might be best to stick to this regardless. I can't really see a reason not to stick to ordering by the values order.

 {% dd(entry.getRootOwner().ratedCurrentOptions) %}
 {% for option in entry.getRootOwner().ratedCurrentOptions %}
      {{ option.label }}{{ not loop.last ? ', ' }}
 {% endfor %}

We can get around this via some filters like so:

{% for option in entry.getRootOwner().ratedCurrentOptions.options|filter(option => option.selected) %}
     {{ option.label }}{{ not loop.last ? ', ' }}
{% endfor %}

But this seems like an additional step to take to match the back-end and front-end.

Steps to reproduce

1. Create a mult-select field with options
2. Pick the options out of order
3. When saving the entry in the back-end the selected options are re-ordered by the original order of the fields options
4. Looping through the field in twig and the order is output as per the 'selected' order not the filed options order.

Expected behavior

The default loop order should match the back-end system view and adhere to the order of the field options.

Actual behavior

The order is shown as the order 'picked' by the author and not the field options order, which also mi-matches what is shown on the back-end.

Craft CMS version

Craft Pro 5.4.6

PHP version

8.3

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

[brandonkelly]

It was definitely not intentional that selected options would be saved in the user-picked order.

Unfortunately it’s not possible for us to just go with that custom order when we re-render the input, because that would require building out the <select> input with the custom option order, so when options are removed, they would continue being placed in the wrong order when the menu is expanded (potentially being placed outside of their optgroups, if defined, as well).

I’ve fixed this for the next Craft 4 and 5 releases by enforcing the field-defined option order when saving new field values, so there won’t ever be a time when the front-end is displaying the user-picked order, for newly-saved elements.

[brandonkelly]

Craft 4.12.6 and 5.4.7 are out with that fix.