Find bug(s) that explain unmatched field type props

String data needs the StringSemantics constraint in order to match against formats etc, so added those to password item props.

The comment_last_name field is computed, so marked that as unsupported (core bug).

Also updated the comments for path fields because the whole field item list is computed.

There's some test fails here because I didn't update the tests to include the 'Article author's password' as a source.

I'm thinking this is a red flag that we shouldn't support password fields ever.

Thoughts?

I'm thinking this is a red flag that we shouldn't support password fields ever.

+1 — I don't see why, either.

I think we should consider special-casing this field type, to ensure it doesn't get listed in \Drupal\Tests\experience_builder\Kernel\EcosystemSupport\FieldTypeSupportTest::SUPPORTED anymore, because we should explicitly not support it.

Removed support for password with an explicit test

green now

The comment_last_name field is computed, so marked that as unsupported (core bug).

What's the core bug? Is "core" referring to Drupal core, or some other meaning of "core"?

What's the core bug? Is "core" referring to Drupal core, or some other meaning of "core"?

I guess the first question is - should we be able to map dynamic prop sources in XB to computed fields in Drupal.

If the answer is yes, then I think we need a core issue to flag those comment fields as computed - but we also need an override in XB to add the string semantics (aka the format key from JSON schema) to that we can ascertain what sort of value they hold.

Can you clarify if the expectation is that you can setup dynamic prop sources against computed fields?

Yes, once we implement dynamic prop sources at all, it should be possible to "link" (the terminology that the UI will use for this) component props to computed fields as well as to computed properties of field items.

I think we need a core issue to flag those comment fields as computed

Oh, is the core bug that it's a computed field but not declared as such (isComputed() returns false)?

Yes that's correct

Ok, so that makes sense that that's a core bug, but why does that matter to XB's shape matching? What are we doing that varies by what isComputed() returns?

Now there's the answer in #13 there is no distinction now (I think).

This needs to go back to needs work as we should be able to remove a lot more of the FALSE items in this list with custom field overrides.