Basic structure of the tool

[jonaseberle]

We suggest:

A Symfony command. It has to be decided if as part of TYPO3 CLI (as an extension) or stand-alone. Pro TYPO3 would be:

• ability to use the TYPO3 API (probably mainly DB, maybe DataHandler)
• ability to use the API of an installed EXT:flux (to be researched if helpful)

Pro stand-alone:

• avoid dependency problems (symfony libs)
• supporting many TYPO3 versions at once is easy

The tool should handle reading flux elements with classes deriving from a base InputPlugin. They shall provide the structure as well as the data. We'll focus on Flux v9 (unclear yet to me if the structure has had changes within v9).

It should write the target element through classes deriving from an OutputPlugin. They shall handle writing content structure as well as the data.

Optional: Users should be able to register their own Input/OutputPlugins.

The usage might look something like that:

vendor/bin/fluxmigrate \
  --from=packages/flux_provider_tpl/Resources/Private/Templates/Content/FluxElement.html \
  --in=fluxV9 \
  --out=typo3TcaV11

[wolffc]

This sounds like a good approach. CLI is the way to go from my perspective. and deployablilty needs to be taken into account.

so the tool needs a DatabaseUpgradeWizzard (or generate one) for every Flux Element). this way new Core Content Elmements can be deployed and the Prevously existing Elements can be migrated at once.

[jonaseberle]

Thanks. I agree that data migration should rather be an UpgradeWizard for each Flux element than a part of the tool.

Generating an extension (composer package type: typo3-cms-extension) per element would simplify deployability and debugging IMHO. The generated package would then be an installable extension, providing all the necessary setup to use the content element + an UpgradeWizard.

We should check if it would be beneficial to use the EXT:flux-API to read element configuration. Then we could decide if it makes sense to run in-TYPO3 alongside EXT:flux or if we pick EXT:flux apart to include in our tool or if we don't benefit from it at all.

I am just continuing to iterate on a possible usage:

$ vendor/bin/fluxmigrate \
  --from=packages/flux_provider/Resources/Private/Templates/Content/FluxElement.html \
  --in=auto \ # default: auto; show possible options with `fluxmigrate input-plugins`
  --out=TYPO3v11 \ # required; show possible options with `fluxmigrate output-plugins`
# options added by the OutputPlugin:
  --outDir=packages/ \   
  --outPackageName=auto \ # default: auto = derive from flux template file name
  --outVendorName=my-vendor # default: fluxmigrate
  --outCType=auto \ # default: auto = derive from package name
# options added by the InputPlugin:
  --inCType=auto # not sure if we can easily get that automatically. 
           # (\FluidTYPO3\Flux\Core::registerProviderExtensionKey(x, 'Content') + <flux:form id=y>?) 
           # - this is something that EXT:flux could help us with in 
           # \FluidTYPO3\Flux\Core::getRegisteredProviderExtensionKeys('Content') if we want to depend on it

...
Created TYPO3 extension as composer package `my-vendor/flux-element` in `packages/flux-element`. 
Install with `composer req my-vendor/flux-element:@dev`.
You can delete `packages/flux_provider_tpl/Resources/Private/Templates/Content/FluxElement.html` now.

$ composer req my-vendor/flux-element:@dev
...

$ vendor/bin/typo3cms database:updateschema
...

$ vendor/bin/typo3 upgrade:run -vv
... # -vv should show the migrated data
Migrated 187 elements of CType `fluxprovider_fluxelement` to `my_vendor__flux_element`.

[stigfaerch]

We suggest:

A Symfony command. It has to be decided if as part of TYPO3 CLI (as an extension) or stand-alone. Pro TYPO3 would be:

* ability to use the TYPO3 API (probably mainly DB, maybe DataHandler)

* ability to use the API of an installed EXT:flux (to be researched if helpful)

Also there could be other API's which could be interesting to be able to use. For example EXT:mask has an API which makes it possible to generate json configuration for mask elements.

[wolffc]

But to use the Mask API it would mean the fluxmigrate tool requires the mask extension. in addtion. and we certainly does not have this in our stack. i would avoid that if not realy nessessary. and as I understand "fluxmigrate" migration from mask is "out-of-scope" for the moment.

[jonaseberle]

I'd also like not to have more dependencies than absolutely necessary. (It's still on me to check if we want EXT:flux but my feeling is "rather not")

If it makes sense for a MaskOutputPlugin, mask/maskcould be in composer suggest with the plugin checking at runtime if it is available. Or... we might make those OutputPlugins separate composer packages anyways (optionally, because having at least the "main" ones in a monorepo will ease development).

We ought to start hacking to see how this fares.