Metadata select fields render in reverse

(Hugh McMaster) #1

Matrix Version: 5.4.3.1

The key and value data for a metadata select field seem to render in reverse on the frontend, when compared to a standard HTML select field (or even the select fields used on a custom form asset).

So, if you enter an option key as “KEY” and an option value as “VALUE”, the option value renders as the option text in the menu, and the key renders as the value attribute of that option.

<select>
    <option value="KEY">VALUE</option>
</select>

But what should happen is that you select the KEY text to send a VALUE to a server in a form etc. Like so:

<select>
    <option value="VALUE">KEY</option>
</select>

Is this a known bug or am I doing something wrong here? The above behaviour certainly differs from a standard HTML select field, and is independent of the Frontend Part metadata field setting.

(Bart Banda) #2

I think it’s just something that has always been labelled like that in the configuration interface. I agree though, the left hand column should be the “Value” column and the right side the “Key” column, I think it’s just a labelling incorrectness. It’s not affecting functionality for you though is it?

(Hugh McMaster) #3

When printing the data attributes of the metadata select field into the browser console, the JSON output matches the configuration interface (i.e. key:value). So, there’s nothing really wrong with the column headings.

The issue is with the rendering of the metadata select fields on the Metadata configuration screen. The “Option Value” renders as the key text (the part you select in the dropdown), and the “Option Key” renders as the <option value="KEY">.

I find this confusing, as it is unexpected and non-standard. Is there any chance a future version of Matrix can render the metadata select field correctly?

(Bart Banda) #4

Yea this is the problem though, because we can’t safely do that without breaking everyone’s implementations. Because of the way they have been labelled in the backend. So for example, if I set the key to “1” and the value “A”, can do things like:

%metadata_field_<fieldname>_key%     //prints "1"
%metadata_field_<fieldname>_value%   //prints "A"

So if we change these, you can imagine it’d break a lot of implementations when they upgrade to the version that has this change implemented.

I agree though, it is a bit confusing them being labelled as such, but I don’t know how we fix that safely without causing issues for people when they upgrade?