Ezplatform Xmltext Fieldtype Laravel Package

Getting Started

This is not a Laravel package — it is the legacy XmlText field type for eZ Platform / Ibexa, packaged so it can be installed alongside eZ Platform v3 purely to run XmlText → RichText migrations. Treat it as a one-shot migration dependency, not application code.

1. Require it in the eZ Platform v3 project that needs migrating (the version constraint matters — 2.x is the v3-compatible line):

   composer require --dev <vendor>/<xmltext-fieldtype>:^2.0
   

2. Register the bundle in config/bundles.php (or the legacy app/AppKernel.php equivalent) so the XmlText field type is known to the kernel.
3. Look first at composer.json (platform/PHP constraints) and the bundle's field type service definitions — those are what the v3 compat work (#104–#119) touched.
4. First use case: point the migration bundle at a database containing ezxmltext attributes and run the XmlText → RichText migration command against a copy of the content database.

Implementation Patterns

• Migration-only lifecycle. Install on a branch/environment dedicated to migration, run the conversion, verify, then remove the dependency. Don't ship it to the runtime production container.
• Pair it with the RichText migration tooling. This field type makes the legacy data readable; the actual conversion is driven by the migration commands/bundle. Keep the two versioned together.
• Scripted runs. v2.0.0 added exit status codes to all commands (Symfony 5 requirement), so you can now chain them safely:

  php bin/console <migration:command> || exit 1
  

  Use this in CI or a wrapper script rather than eyeballing output.
• Staged rollout. Migrate a content subset first (one content type / one subtree), diff the resulting RichText XML, then run the full set.
• Legacy round-trip check. Keep a read-only snapshot of the pre-migration ezxmltext data so you can re-run conversion after fixing mapping issues — the migration is destructive to the field's representation.

Gotchas and Tips

• 2.x is migration-only. Per the release notes, the 2.x line is supported only for XmlText → RichText migration. It is not a supported runtime field type for authoring; don't enable it for editors.
• Same features as 1.9.2. v2.0.0 is purely a platform-compatibility release. If you're still on eZ Platform v2, stay on 1.9.x; upgrading buys you nothing and the v3-only changes may not apply.
• Breaking for anyone extending the field type:
  • Deprecated field type tags were replaced (#105) — service tags in your own overrides must be updated.
  • Class parameters were removed (#106) — if your config or custom services reference parameters that previously pointed at field type classes, those references will now fail. Inject services/class names directly instead.
• Symfony 5 exit codes change command behaviour: scripts that previously ignored failures may now abort. That's an improvement, but audit any wrapper that used set -e-less chaining.
• This assessment is framed as a Laravel package but the artifact is eZ Platform/Ibexa. There is no service provider, facade, config file, or Eloquent integration. Don't look for config/xmltext.php — it doesn't exist.
• Extension point of last resort: if the migration mangles a specific XmlText tag, patch the converter/field type locally behind a Composer patch, log the offending content IDs, and keep the patch list — you will not get upstream support for edge cases in a migration-only package.