[5.x] Field that is not MultiInstance still uses a different UUID in each field layout

[janhenckens]

While upgrade my Date Range plugin, I ran into the following issue/oddity.

The plugin has an EntryQueryBehaviour where the user passes the field's handle (eg craft.entries.section('events').isPast('dateRangeHandle'), which then allows the behaviour to do it's logic based on the value from the field that it got passed.

In Craft 5, when I get the field through Craft::$app->getFields()->getFieldByHandle($handle), it returns null when I try to get ->getValueSql() - even when the field isn't MultiInstance.

As a work-around, I added a second argument the user has to pass to the behaviour, which is the entryType handle:

$type = Craft::$app->getEntries()->getEntryTypeByHandle($this->entryTypeHandle);
$layout = Craft::$app->getFields()->getLayoutById($type->fieldLayoutId);
$this->field = $layout->getFieldByHandle($this->handle);

That field does give me a valueSql()

Secondly, when checking the database, the UUID under which the data is stored is different for each entry type - even if the field doesn't have MultiInstance enabled.

I'm ok with my workaround but I wanted to make sure that the different UUID for each entry and the null result is intended behaviour.

[brandonkelly]

This is all working as expected. Each field layout component gets a unique UUID, which custom fields use as their “instance UUID” regardless of whether they’re multi- or single-instance field types.

If you are using valueSql(), I take it the field is still getting content stored in the content JSON column. So is there a reason the field is limited to be single-instance?

[janhenckens]

The field is/was being stored as JSON, but mostly using valueSql() because the behaviour needs to do a query on one or both of the values (start & end date).

I tried to disable it initially, to see if that would negate the need to pass the entryType to the behaviour. But I'll need that to get the instance UUID so I could make it MultiInstance now either way.