Component Source plugins: support for schema changes of explicit inputs

Created on 15 May 2025, 19 days ago

Overview

After careful discussion with @effulgentsia, this was descoped from 🌱 [META] Production-ready ComponentSource plugins Active ; we will NOT need it for 🌱 Milestone 1.0.0-beta1: Start creating non-throwaway sites Active , we will LIKELY need it for 🌱 Milestone 1.0.0: Production Sites Postponed . Details TBD.

Explicit input schema change strategies: This is a hard blocker for 🌱 [META] Production-ready data storage Active .

Introduce

enum ExplicitInputSchemaChangeStrategyEnum: string {
  case LogicUpdatepath = 'logic_update_path';
  case OnlyNetNewOptional = 'net_new_optional';
  case Manual = 'manual';
}

Each ComponentSource plugin MUST pick 1 of these.

Implement the LogicUpdatepath strategy, use it for the "block" component source, and use it to prove that A) a block plugin's changing input schema (which should trigger a new version, see 2 steps earlier) also can result in e.g. a new required block setting being added automatically, B) explicit test coverage should prove that a block with changing explicit input schema without an update path provided should result in its Component config entity getting disabled (to prevent new instances), and that thanks to 🌱 [META] Robust component instance error handling Active , existing component trees continue to render fine.
TBD whether this is done using the existing update path hooks, or whether we require a new PastConfigurableInterface to be implemented by block plugins — which would then also become a new requirement for the block component source plugin.
👉 📌 [SPIKE] Prove that it's possible to apply block settings update paths to stored XB component trees Active
Implement the OnlyNetNewOptional strategy, use it for the "sdc" component source, and use it to prove that A) an SDC adding a new optional property works fine, B) explicit test coverage should prove that an SDC with a new required with changing explicit input schema without an update path provided should result in its Component config entity getting disabled (to prevent new instances), and that thanks to 🌱 [META] Robust component instance error handling Active , existing component trees continue to render fine.
Implement the new Manual strategy, use it for the "js" component source, and prove that anything is allowed, but it should require explicit confirmation IF AND ONLY IF >=1 component instances will be affected. → 🛑 depends on 📌 Calculate field and component dependencies on save and store them in an easy to retrieve format Active from 🌱 [META] Production-ready data storage Active