In #3523841: Versioned Component config entities (SDC, JS: prop_field_definitions, block: default_setting, all: slots for fallback) + component instances refer to versions ⇒ less data to store per XB field row we added support for versioned components.
There are places in the front-end code where we consult the components endpoint to get field data/json schema about a component that might need updating.
Consider a scenario where we have an old version of a component in the page - the components input form correctly renders the old version of the form (widgets etc) but the front-end might be getting json schema and hence validation rules for the current version.
Add an e2e test to validate that we can edit old versions.
If it fails, address places in the FE where we consult that list and explore how we could pass the 'point in time' validation rule for legacy versions.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
wim leersGood call.
Comment #3
wim leersComment #4
wim leersEspecially important now that we've discovered (and fixed) #3536277: Data loss: `ComponentTreeItem::setValue()` and `::onChange()` may inappropriately upgrade `component_version` to the latest version (and kinda also #3538503: Disallow component trees with `component_version: active`). This would be the finishing touch to boost our confidence 🤓
Comment #5
larowlanI went looking for any existing tests that enable xb_test_storage_prop_shape_alter which would be the obvious way to test this and found component-transforms.cy.js which looks to do exactly what we were looking for here.
That was added in #3515629: FieldWidget's XB transforms must be bubbled by the Field Widget rendering to inform the client which was early May, but this issue was opened in June - so that leads me to believe it might not be enough on its own.
I will recreate the steps in that test and see if it is already providing the coverage we need and expand it as needed.
Comment #7
larowlanExpanded the existing test to assert that the input in the old component version passes validation.
Because our validation is tied to the json schema and that _doesn't_ change I think we're in good shape here
Comment #8
wim leersThat was fast!
Comment #9
wim leersI'd have liked to see a more comprehensive end-to-end test, but I see now that the issue summary was quite specific about this: so 👍
It is very nice to see such a nice little expansion of an existing test though, so merging this; more expansive test coverage will be necessary in #3463996: [META] When the field type, storage/instance settings, widget, expression or requiredness for an SDC/code component prop changes, the Content Creator must be able to upgrade anyway :)
Comment #11
wim leers