Legacy bundles (EZP-22210) follow-up stories

legacy_bundles_followup.md

Follow-up stories for legacy bundles

Original story: EZP-22210

Semi-automatic null FieldType mapping

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).

Autoload generation on install

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.

Backoffice customization using new stack code

• 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)

Would be great if, probably, after all the symlink process has finished, we could convert the translation.ts files contained on the translations folder to the Xliff format. (i say Xliff because i think is the preferred way to go in Symfony)

• That process could iterate over all subfolders contained in the translation one.
• For each subfolder, it should check if translation.ts is present
• If so, then the conversion process starts
• The conversion process would craete a xliff format having messages.[subfolder].yliff as name and place it in the Resources/translations bundle folder

things to take in account

• We must deal with translation.ts context. The equivalent for that in Xliff are "domains"
• As legacy context usually have slashes (design/admin/content/search), should we replace for something else like underscores?

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.