When a field instance used by a `ContenTemplate` is deleted, or a field-type providing module is uninstalled, replace affected `inputs` with default `StaticPropSource`

This is inaccurate.

ComponentTreeItem doesn't allow DynamicPropSources. That's been the case since #3481720: Tighten validation: only allow StaticPropSource in XB fields + PageTemplate, DynamicPropSource in ContentTypeTemplate.

Only ContentTemplate config entities' (being introduced in #3517741, which spawned this issue to keep scope tight there) component trees will be allowed to use DynamicPropSources.

Added the proposed resolution. Can you confirm it makes sense to you? 🙏

If it does, please update the Overview in the issue summary — that's why I tagged this for needing an IS update.

Im pretty interested in following the ContentTemplate work, so I figured I'd make a start on this one based on the IS and the discussion from #2. I've pushed up a POC of the existing work I've done so far, which now adds config dependencies for fields to the content template entities. This has test coverage, but still additional work to be done around code cleanup and removing the legacy code from `ComponentTreeItemTest`

Woohoo, thanks so much! 😊

Per #3518248-11: [PP-1] Content templates, part 4 (boss battle): create a UI for editing templates, this should block that.

We certainly should not delete the whole content template as a result of deleting a field. 😅 I think we should just remove the use of the dynamic prop from the content template. In case the deleted field happens to be a required, we replace the dynamic prop expression with example value.

This sounds like it's more of a frontend issue, then,

How/why do you conclude that? 🤔 😅

It's not the front end that is deleting a FieldConfig; that's a pure server-side concern. It might also happen through a configuration sync.

This is the ContentTemplate equivalent of #3484682-12: Handle update and delete of Block `Component`s, plus react to dependency removal: we need to implement ContentTemplate::onDependencyRemoval().

This is at minimum soft-blocked on #3457504: XB field type: calculate all dependencies, store them, surface in new Component "Audit" operation, but not yet sure whether I should hard-block it on that. Your help on that issue would surely be appreciated, @phenaproxima 🙏

So: @lauriii and I +1'd @phenaproxima's proposal in #10:

We probably need ContentTemplate to implement onDependencyRemoval()

… and I missed that while writing #13 — but you can see that there's other cases where we still need to do that, @phenaproxima — it'd be nice for you to lead the way here :)

See #3457504-33: XB field type: calculate all dependencies, store them, surface in new Component "Audit" operation — as of that moment, that MR implements a superset of ComponentInputs::getDependencies() that this MR was adding.

That means that:

1. This is now hard-blocked on #3457504: XB field type: calculate all dependencies, store them, surface in new Component "Audit" operation — because that other MR clearly is the more precise, complete, reliable solution.
2. This issue can now be rescoped to handle the ::onDependencyRemoval() part 🥳

@phenaproxima: can you please help finish that issue? 🙏

Related, from ~10 months ago, where we predicted exactly this issue: #3452848: [PP-1] Test coverage to prove configurable fields cannot be deleted from content entity types if they are used in XB Content Type Template.

#3457504: XB field type: calculate all dependencies, store them, surface in new Component "Audit" operation is in!

The current MR is AFAICT obsolete; everything in it has already been implemented (in a more comprehensive manner) in #3457504.

That means that the remaining scope here should be implementing (and testing) ::onDependencyRemoval().

The content template should not be deleted.

Indeed!

This should make XB to fall back to the default (example) values for those inputs.

Yes, that's what @lauriii proposed in #11 👍
In my mind, we would just delete the component instance. But … I think what you propose here (and I guess makes more sense indeed! 😄

So:

1. I have a ContentTemplate (for article nodes) with a hero component instance whose marquee prop is populated by
   

   {
     "marquee": {
       "sourceType":"dynamic",
       "expression":"ℹ︎␜entity:node:article␝field_funny_message␞␟value"
     }
   }
   

   i.e. it fetches the value field property of the field_funny_message field on the article node type.

   This was a DynamicPropSource.

2. The site builder wants to delete field_funny_message; and it's not reasonable for a ContentTemplate to block that, but the ContentTemplate should also not be deleted.
3. ContentTemplate::onDependencyRemoval(), checks iterates over all component instance inputs and finds the one that actually depends on this particular field (i.e. on the field.field.node.article.field_funny_message config). It replaces the DynamicPropSource with a StaticPropSource.

   Rough outline of algorithm:

   1. Check if this component requires explicit input ComponentSourceInterface::requiresExplicitInput(). If not: [] (the empty array)
   2. Sanity check: assert that Component::getSource() instanceof GeneratedFieldExplicitInputUxComponentSourceBase — only these sources can be populated by fields.
   3. (Untested PoC.) Populate all props with examples (which means: all required ones, plus the optional ones that do have an example).
      

      $component = Component::load(…);
      $source = $component->getSource();
      assert($source instanceof GeneratedFieldExplicitInputUxComponentSourceBase);
      if (!$component->requiresExplicitInput()) {
        return [];
      }
      
      // @see `type: experience_builder.generated_field_explicit_input_ux`
      $props_with_examples = array_keys(array_filter(
        $source->getSettings()['prop_field_definitions'],
        fn (array $def) => $def['default_value'] !== NULL
      ));
      return array_map(
        fn (string $prop_name) => $source->getDefaultStaticPropSource()->toArray()
        $props_with_examples
      );
      

      👆 This should return something like

      {
        "marquee": {
          "sourceType":"static:field_item:string",
          "value": "Hello, world!",
          "expression":"ℹ︎string␟value"
        }
      }
      

      (You will need to refactor GeneratedFieldExplicitInputUxComponentSourceBase to make certain methods available to ContentTemplate. For alternative implementation inspiration, see GeneratedFieldExplicitInputUxComponentSourceBase::buildConfigurationForm()).

   4. ComponentSourceInterface::validateComponentInput() on the end result
   5. Prior to saving, verify the end result by using \Drupal\experience_builder\Plugin\Validation\Constraint\ValidComponentTreeConstraintValidator::validate()

   IOW: kinda like \Drupal\Core\Entity\EntityDisplayBase::onDependencyRemoval() :)

Very close!

And very nice to see the new ComponentSourceInterface::getDefaultExplicitInput()!

This is now only missing test coverage IMHO: https://git.drupalcode.org/project/experience_builder/-/merge_requests/9...

@phenaproxima, also, correct me if I'm wrong, but AFAICT #3452848: [PP-1] Test coverage to prove configurable fields cannot be deleted from content entity types if they are used in XB Content Type Template is made obsolete by this issue, isn't it? 😄🥳

Basically only a naming remark left — other than that, this is is IMHO good to go!

Please assign this to @longwave for final review after you've addressed the naming nit.

@longwave, I think the new ::getDefaultExplicitInput() should be used in multiple places in GeneratedFieldExplicitInputUxComponentSourceBase — curious if you agree. That'd allow us to be more confident about it IMHO.

I haven't reviewed the rest of the code in detail, but I think Wim is confident with it; back to @phenaproxima for a review on the part I just changed then I think you can RTBC if you are happy with that?

Pushed a further refactor that removes another ~10 lines of code because it looks like we can assume default_value is always set. If this fails tests then let's revert and move that to a followup.

Thanks Wim - was about to dig into this this morning but you've beaten me to it. I think we could handle the "new prop" case in a followup somewhere and finish the refactor, but let's not hold this up any more.

Was failing tests. Wanted to see this through, so debugged, and found that reverting a single line was sufficient to make it pass. Added a clarifying comment.

Glad to have @longwave's +1 for the new GeneratedFieldExplicitInputUxComponentSourceBase::getDefaultExplicitInput().

Agreed with @longwave's suggestion to improve it + adopt it more widely in a follow-up. Tagging for that. (That will be squarely in the Component sources issue queue component, rather than issue's Config management. 👍)

@phenaproxima's additions of ComponentInputs::getPropSourcesWithDependency() and ComponentTreeItem:: updatePropSourcesOnDependencyRemoval() look fantastic (plus, the test coverage of course). The latter new method will undoubtedly come in handy when updating the Pattern and PageRegion config entities. Created #3524345: Avoid deleting `PageRegion`s & `Pattern`s when uninstalling field type-providing module: implement `::onDependencyRemoval()` , replace with default StaticPropSource for that.

Cross-posted with @longwave in #43 — obviously we agree 😁

Updating title, because thanks to ::testRemoveFieldTypeProviderModule(), @phenaproxima actually solved more while at it 🥳

The missing config dependencies part was actually solved in #3457504: XB field type: calculate all dependencies, store them, surface in new Component "Audit" operation.