Status: Specification Done
Affects Version/s: 2.5.6, 3.0.0-beta3
Fix Version/s: None
Sprint:Candidates for next sprint
We've removed some previously deprecated FieldTypes from our configuration and initial data, but we also need to provide the Developers a way to "upgrade" their existing installation by removing Field Type of the given identifier from database (multiple core tables are involved).
Otherwise it leads to errors like this:
This is in general useful cleanup feature and useful enough to provide it in 2.5.x.
TBD: how we can drop external storage data in a generic way (for 3rd party Field Types).
TBD: if the errors occur while loading container or during runtime (in the former case spec will need adjustments):
To be implemented as the ezplatform:upgrade:delete-field-type Command provided in EzPlatformCoreBundle.
Usage: php ./bin/console ezplatform:upgrade:delete-field-type <field-type-identifier> [options]
The command options:
- --delete-from-content-types (default: no/false), but provide a warning that CT won't be affected unless this is set
- --content-id=<int:content-id>, provided as an array argument, cannot be combined with -delete-from-content-types (throw an exception),
- --subtree=/1/2/ cannot be combined with -delete-from-content-types (throw an exception),
- --dry-run reporting number of elements to delete,
- Privileged user argument, let's use sudo (based on my experience).
- Iteration count argument. Deletes should be fairly light. Rather won't do any loading anyway due to possible exceptions (see above).
It would be useful if the command reported left-overs, like existence of an External Storage, existence in Content Types, existence in the container (services providing FTs).
This feature can be split into smaller iteration-based sub-tasks.