Component instances will auto-update to active version of the Component config entity when the upgrade has no data storage implications that could cause data loss.
See the attached gif to see it in action when new media types are added:
For component source developers:
If you maintain your own component source plugin (⚠️ despite this not yet being a public/supported API with backwards compatibility guarantees — so thank you for being an early adopter! 💙), you can define an updater class in your ComponentSource annotation, which must implement \Drupal\canvas\ComponentSource\ComponentInstanceUpdaterInterface.
If your component source does not provide an explicit input UX (aka extends from \Drupal\canvas\Plugin\Canvas\ComponentSource\GeneratedFieldExplicitInputUxComponentSourceBase), you should just define \Drupal\canvas\Plugin\Canvas\ComponentSource\GeneratedFieldExplicitInputUxComponentInstanceUpdater
For recipes developers:
Until now, if your recipe provided page regions, patterns or content templates, you were forced to provide your Component config entities, as their trees are requiring the referenced versions to exist on the components.
With no auto-updates, this meant that if you were targeting Drupal core and Drupal CMS providing a component that depended on e.g. media, you had to choose:
- Not allowing Drupal CMS SVG media images to be selected.
- Having to provide different recipes with slightly different config for Core and CMS.
Now, you can just provide your component versions for Drupal core, and they will be auto-updated for Drupal CMS.
In the future, we are evaluating reducing these requirements further. Follow #3571366: Allow Canvas Patterns+PageRegions+ContentTemplates provided by Recipes to NOT specify component versions if this is on your best interest.
