Make webform blocks (block.webform.block:*) fully validatable so they can be used in Experience Builder

Added steps to reproduce with screenshot from config inspector and guidance on where to find compatibility checking in XB.

Looked a bit at this with Gábor.

This will be the first step to make Webforms XB compatible, but not enough. I'd suggest we keep the scope here to make it FullyValidatable.

The bad news, as this uses a yaml blob in its config, a custom xb transform will be needed for the widget.
The good news, parts of this aparently was done already in WebformTranslationConfigManager for compatibility with config translations form integration.

Added 📌 Add xb transform to webform block storage so that it works with Experience Builder Active for that, so we can keep scope there.

Thanks for looking into this! Tested the MR. The webform block I created is almost validatable now :) The provider and webform block ID seems to have errors still in config inspector:

I don't know if this block has all the keys that webform blocks have all the time, but if it does, then solving these two would solve it for all webform blocks :)

I also looked at the component list in XB and it still says that it is not validateable indeed.

@penyaskito could you point me in the direction of a custom xb transform that has already been implemented?

Expanding the scope a bit, since this could be about the initial working version of it which seems to not be too far off.

Let's keep the scope of showing up as dynamic component which is already achieved :)

Fails are unrelated to this MR, so moving to Needs review. I think it fulfills what it was meant to do. Webform maintainer decision is needed as to whether the block dropdown makes sense compared to the autocomplete. I think its a better user experience, but could indeed get unwieldy if someone has a loooooooot of forms.

I think if there are over 100+ webforms using an autocomplete is a better UI/UX. Perhaps we should address that decision in a new ticket.

Makes sense. Ideally it would not even be needed if the autocomplete would properly hold the value in XB. Rolled that part back in interest of moving this forward :) I think the block validatability changes are noncontroversial :)

Looks good.

Made diff permanent for composer patching until a release of webform includes the fix.

I don't think this is entirely correct...you also need to explicitly mark the data structure as fully validatable by adding:

constraints:
  FullyValidatable: ~

Or, as far as I know, XB won't recognize it.

Opened a second MR with the required fix.

For details, see the change record that introduced FullyValidatable in core: https://www.drupal.org/node/3404425 →

Isn't FullyValidatable deduced from the data structure being fully validatable? We would only need to specify it if we want to work around parts of the data structure not being validatable and we want to force it?

While XB does tell us the webform block config is not validatable, it does not tell us why. If you place a webform block and check it with config inspector, nothing under its setting is impossible to validate. (The top level of webform's settings says validatable).

In @wim.leers words:

XB doesn’t use Block config entities
It uses BlockPluginInterfaces aka block plugins
So XB stores a subset of what Block config entities store: only `

settings:
  type: block.settings.[%parent.plugin]

aka block.block.*:settings
See \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::checkRequirements() :

$data_definition = $this->typedConfigManager->createFromNameAndData('block.settings.' . $block->getPluginId(), $settings);

But this part is already entirely validatable as proven by config inspector (see screenshot). If we need to add FullyValidatable manually to config trees that are already fully validatable, that sounds like a lot of extra things to do, and it will potentially lead to problems if new not validatable keys are introduced accidentally, which the workaround will paint over and hide.

Ok I was misguided. FullyValidatable does not mean what the name suggested to me it meant. That config inspector says a tree is entirely validatable does not mean it is FullyValidatable, because FullyValidatable is a strict validation opt-in flag, not a status indication of the validatability of a tree. So it is something that must be explicitly added and is not deduced. In short it means that all values are required by default under the key where it is specified and all keys of a mapping must be present.

More at https://www.drupal.org/node/3404425 →

So yeah we do need to opt in to the strictly validated for webform blocks to show up in XB, sorry for the prior confusion.

Based on that updated understanding I proposed an update to the XB error at 🐛 DX: Block plugin full validatability message may be misleading, add concrete next steps Needs review which just got merged. So that explains clearly that we need to add FullyValidatable after all.

Combined patch for xb-demo until later tagged version includes this.