@lukasbestle @distantnative I think we need also implement the field prop to following lines?

• https://github.com/getkirby/kirby/blob/feature/items-field-prop/src/Cms/Layouts.php#L101
• https://github.com/getkirby/kirby/blob/feature/items-field-prop/src/Form/Field/LayoutField.php#L32
• https://github.com/getkirby/kirby/blob/feature/items-field-prop/src/Form/Field/LayoutField.php#L149

@afbora Those are part of the reason why the $field prop is optional (the other reason being that it avoids the breaking change). I don't think we can get to the field object easily from these places.

Edit: Forget what I wrote, I think it should actually be doable. Thanks for spotting! Do you have time to update the code? Otherwise let's move this to 3.9.3.

Do you have time to update the code?

Actually this is easy for first one but other two ones are a little complicated since that ones inherit Form\FieldClass not Cms\Field.

Possible solutions in my mind:

1. Support FieldClass class: protected Field|FieldClass|null $field;
2. Add new field prop/method that returns new Field object to FieldClass class.

Which way do we should follow?

The goal of the new field prop is to make UUIDs for blocks possible in a future version. So I think we can't make it a form field, it needs to be a content field.

I've created a PR that fixes CI workflow issue #5055

@afbora Thanks for updating the Layouts code and force-pushing the branch again.

I checked the other two uses in LayoutField again: I don't think we'll need to update those anyway as these calls won't be relevant for block UUIDs. Or if they are, we could still update them when we get to it. Maybe we'll have refactored the field setup anyway by then.

So looks good to me. Maybe @distantnative can have a final look before we merge this.