Original story: EZP-22210
Benefit: makes it easier to soft migrate legacy datatype extensions to the new stack Usefulness: 7/10 (BD)
A common use-case in projects would be to map an existing, custom legacy datatype to the Null FieldType.
Any datatype extension can easily be copied to a bundle. In order not to error out on the new stack, the most basic operation is to map the datatype to the Null FieldType, by means of services definitions.
Write a compiler pass that looks for datatypes in the Resources/ezpublish-legacy folder. For each datatype found, if no matching fieldtype is registered, we declare a new service that maps the datatype to the Null FieldType (NEED DETAILLED USE-CASE).
Benefit: removes a legacy specific manual step that is easily forgotten when installing a custom extension Usefulness: 4/10 (BD)
Provide a composerpost-update script that can be used in legacy bundles, that updates the legacy extension and kernel override.
Possible issues: it could, if there are several updates, run the autoload scripts more than once.
- create a new content tab / backoffice tab (specify title, template. Inject into legacy, run callback LS=>NS)
- fake custom modules (execute a controller from the new stack)
Sorry, what i proposed is more for existing extensions than for new ones. In new Bundles there shouldn't be need to have translation.ts files at all.