I appreciate all the work that went into this PR. Thank you.

Due to a change in 0b85403 the ButtonGroup fieldtype cannot display a button as active, if the key is a number. This is because the HTML button uses strings for its value, but the PHP side will cast numeric values to numbers, which then will fail the === comparison.

Why can't we just make it a loose comparison in the JS instead?

Changing this to a loose comparison seems to solve the problem without any PHP changes needed.

Also, if you change the default options for the Width fieldtype the resulting list will contain integer and string keys. It breaks the Width fieldtype to properly display the selected width, because it uses a strict comparison, too.

It seems to work fine for me. It already uses a loose comparison.

I appreciate all the work that went into this PR. Thank you.

Due to a change in 0b85403 the ButtonGroup fieldtype cannot display a button as active, if the key is a number. This is because the HTML button uses strings for its value, but the PHP side will cast numeric values to numbers, which then will fail the === comparison.

Why can't we just make it a loose comparison in the JS instead?

cms/resources/js/components/fieldtypes/ButtonGroupFieldtype.vue

Line 13 in 13d2aed

:class="{'active': value === option.value}"

Changing this to a loose comparison seems to solve the problem without any PHP changes needed.

I thought about changing these types to ensure a better consistency. The PHP change actually affects the label type only, enforcing it to be a string always, but maybe it is better to leave it untouched. I changed it back, leaving the Unit Tests though to also test the return types for values and labels, if the source values are numbers. I tested the code without enforcing string value within HasInputOptions.js and changed the comparison to a loose comparison. I realized though, that in this case the update handler should use the original option value, instead of the $event.target.value, so that the update event always uses the same type as the :value binding. Otherwise, numbers would be casted to strings at this place. However, this would also store the value as numbers in the flat files, which could lead to unexpected behaviour, if someone checks the raw type of the entry value. The augmented/computed value still returns a number though.

Also, if you change the default options for the Width fieldtype the resulting list will contain integer and string keys. It breaks the Width fieldtype to properly display the selected width, because it uses a strict comparison, too.

It seems to work fine for me. It already uses a loose comparison.

cms/resources/js/components/fields/WidthSelector.vue

Line 16 in 13d2aed

{ 'filled': selected >= width, 'selected': selected == width }

Yea, it works :)