ComponentNotFoundException: Unable to find component

This is a standard part of the process so I'm changing this to a bug. In the meanwhile, it would be helpful if we can provide @kristen pol some guidance on how to workaround this until we have a proper solution for this.

This is not a bug. Switching git branches and hence suddenly having different git branches is the equivalent of running Drupal with module X installed, switching git branches, and the other git branch not having that module present in the codebase.

Solution: two parts

That being said: yes, we need to guard against this. We need to distinguish between:

• Extensions providing SDCs getting uninstalled (i.e. the "site builder" scenario, not the "developer" scenario): if there's zero component usage, then this is fine/safe, otherwise, we must refuse the extension getting uninstalled. This is the "component present in tree" equivalent of 📌 Prevent fields from being deleted if they are used in Experience Builder field's dynamic prop values Active (which does "field type present in props".
• Extensions providing SDCs changing from one request to the next (i.e. the "developer" scenario). TBD, but I think detecting whether development mode is on (see https://www.drupal.org/node/3359728 → ) and if then this exception is thrown, we should auto-delete on-the-fly and use \Drupal::messenger() to inform the developer with a warning.

  Unblocking this workflow TODAY

  • ❌ Temporary work-around: vendor/bin/drush config:delete experience_builder.component.starshot_demo+old-starshot-one-col — but this is one-by-one 😬
  • ✅ Temporary work-around:
    

    vendor/bin/drush sql:query "DELETE FROM config WHERE name LIKE 'experience_builder.component.%'"
    vendor/bin/drush cr
    

This is closely related to 📌 Component config entity should validate that the SDC actually (still) exists Active .

Yay! Happy to have the manual workaround 🙌 I’ll add to our docs.

Added here:

https://www.drupal.org/community-initiatives/starshot-demo-design-system... →

Thanks!

Today during my testing i observed this issue is still present, workaround from #3 did the fix for me.

@lauriii reported a duplicate at 🐛 Error after updating a theme Closed: duplicate and @guptahemant spotted that. Crediting both.

@longwave opened an issue for essentially the same problem: 📌 Handle update and delete of SingleDirectoryComponent `Component`s, plus missing config dependencies Active . I'll let him decide which of the two issues to keep around :) Or maybe he wants to repurpose this for a more explicit DX enhancement, such as a \Drupal::messenger()-powered warning for SDC developers when Twig dev mode is on? 🤓🤔

🐛 Cannot delete JS components due to component depending on them Active might solve most of this.

Contrasting this with 🐛 Cannot delete JS components due to component depending on them Active 's updated title.

Making it very explicit how this relates to 🐛 Cannot delete JS components due to component depending on them Active .

🐛 Cannot delete JS components due to component depending on them Active is in!

The config dependencies part is definitely already taken care of. This is about a module/theme containing an SDC one moment, and not the next.

Closed 🐛 Component definitions not updating when clearing cache Active in favor of this.

There I created an MR that would "solve" the problem for SDC. That one takes a drastic approach: if a component is not found when rebuilding, it will just delete the component entity.

In #3 this was mentioned as a potential approach if (and only if) the development mode → is set.

But here the IS mentions the 3 Canvas-provided cases (blocks, SDCs and even JS components) scenarios.
We cannot rely on this happening only when in development mode. Not best practice, but a block plugin, or an SDC could disappear in a new release of a contrib/custom module/theme, so this wouldn't be only happening in a development scenario.

I wonder if we should:

a) Check if in development: then just delete the component and warn the user.

b) If not:
That's the real complex case. I'd suggest we implement an on-the-fly upgrade process (for existing content) that would convert those to the fallback component keeping its inputs/settings. That's something that was mentioned already for e.g. migrating from layout builder or paragraphs, so it's infrastructure we want to create anyway for any potential component source.

But we still would need to delete the component, as even disabling the component requires the e.g. SDC to exist (is verified on save). If we think this is too drastic, then we would need to try/catch everywhere in canvas and assume that the missing component on discovery is a valid state for a project.

Transferring beta blocker tag from the duplicate issue.

Beta blockers are by definition also stable blockers, but removing the latter tag in order to make it easier to scan a queue of stable blockers that aren't also blockers to beta or RC.