Gracefulness when developing SDCs: SDCs may appear/disappear from one request to the next

🇫🇮Finland lauriii Finland

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.

Assigned to f.mazeikis

Comment 3 months ago →

🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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
```