Xrowmetadata Bundle Laravel Package

Getting Started

This bundle is a legacy bridge: it wires the xrowmetadata eZ Publish 5 extension (a custom datatype) into the Symfony/eZ Publish 5 kernel so the datatype can be used on content classes. Treat it as maintenance-only — the last tagged release is 2017 and the description literally says [deprecated]. If you are not already on an eZ Publish 5.x / legacy-bridge codebase, do not adopt it.

Minimal steps to get it usable:

1. Confirm your stack. You need eZ Publish 5.x (or an eZ Platform install that still ships the legacy bridge and legacy kernel). PHP should match whatever the legacy kernel supports (typically PHP 5.6–7.1). It will not work on modern eZ Platform 3.x / Ibexa.
2. Install via Composer (from a fork or VCS, since packagist metadata is stale):

   composer require xrow/xrowmetadata-bundle
   

   If resolution fails, add a vcs repository pointing at the GitHub repo and pin a commit.
3. Register the bundle in app/AppKernel.php:

   new Xrow\XrowMetadataBundle\XrowMetadataBundle(),
   

   Place it after the eZ Publish bundles so the legacy extension registration runs correctly.
4. Regenerate the legacy autoload and clear caches — this is not optional, the legacy datatype registry is cached:

   php app/console ezpublish:legacy:script bin/php/ezpgenerateautoloads.php
   php app/console cache:clear --env=prod
   

5. Where to look first: the bundle's eZ/Publish/Extension/legacy extension/xrowmetadata directory (the actual datatype definition), its DependencyInjection/ config, and the Resources/config service definitions. The datatype class itself (usually xrowMetadataType) is where the day-to-day behavior lives.

First use case: add an xrowMetadata attribute to a content class in the legacy admin, edit a content object to populate it, then read the value back from a Twig/controller to verify the legacy bridge is passing the attribute through. That single round-trip tells you whether the bundle is wired correctly — everything else builds on that.

Implementation Patterns

Because the bundle is a thin bridge, most work happens through the eZ Publish content API and the legacy stack rather than through bundle-specific services.

• Content class setup. Create the xrowMetadata attribute via the legacy admin Content classes screen, not via a Symfony form. The datatype needs to be registered in the legacy datatype map (the bundle's extension should handle this on activation). Once registered it appears alongside ezstring, ezxmltext, etc.
• Reading values in controllers. Use the public API and cast to the datatype:

  $content = $contentService->loadContent($contentId);
  $field   = $content->getField('metadata');      // your attribute identifier
  $value   = $field->value;                      // xrowMetadata\Value object
  

  Depending on how the datatype stores data, $value is either a scalar wrapper or an array of sub-attributes; inspect the Value/Type classes before assuming a shape.
• Rendering in Twig. With the legacy bridge, ez_field_value(content, 'metadata') returns the raw value; for structured metadata you usually serialize it in a small Twig extension or read it via ez_render_field. Avoid relying on the legacy attribute_view_gui templates unless you ship them — the bundle does not guarantee front-end templates.
• Writing values. Go through ContentService::createContent / updateContent with a proper FieldValue built from the datatype's Value object. Direct ezcontentobjectattribute writes are the shortcut everyone reaches for and the reason people later can't figure out why the admin UI shows stale data — the datatype's fromString/toString won't have run.
• Workflow integration. Metadata fields are commonly populated on publish. A legacy workflow event or a content.publish Symfony event subscriber is the right hook; mutate the field on the ContentCreateStruct before publishVersion, not after.
• Extending the datatype. Add sub-attributes by editing the legacy Type::initialize* methods (which define the field definition) and mirroring the change in the Value class and the admin template. There is no clean extension point — this is a fork-and-edit datatype, so keep the change list short and documented in your repo.
• Multi-environment. Datatype changes are content-class changes, which are stored in the DB, not in code. Keep a DB seed or class-export script per environment; do not assume git pull propagates a new attribute.

Gotchas and Tips

• Deprecation is the headline gotcha. No maintainer, no security fixes, PHP 5.x-era code. Anything you build on it is effectively frozen. Confine it to one content class and isolate it behind your own service so you can swap it later.
• The legacy bridge is fragile. Bundle registration order matters; the datatype registry is populated during legacy extension activation and cached. If the fieldtype is missing from the admin dropdown, run the autoload regeneration step again and clear both Symfony and legacy caches (var/cache and ezpublish_legacy/var/cache).
• Composer resolution will likely break. The package predates modern Composer constraints; you'll often need --ignore-platform-reqs, a locked PHP version, or a VCS fork. Pin it explicitly.
• Data shape ambiguity. The Value object is not well documented. Dump it (var_dump, or dump() in a controller) once per attribute before writing template logic — assumptions about scalar vs. array storage cause silent template errors.
• Editing content outside the API corrupts expectations. Stored as serialized/legacy-attribute data. Always round-trip through ContentService; SQL-level edits skip fromString/toString and the datatype will appear to lose data.
• Debugging goes through the legacy stack. Symfony's profiler won't help with datatype internals. Use the legacy debug output (ezdebug / debug settings in ezpublish_legacy/settings/override/siteaccess) and error_log inside the datatype methods.
• No front-end rendering contract. Do not assume templates ship with the bundle; check Resources/views and the legacy extension's design/ folder, and be prepared to write your own attribute_view_gui template.
• Migration path. If you can, replace the field with a native fieldtype (eZ Matrix/ezmatrix, or in modern Ibexa a custom FieldType) before you're forced to. The metadata concept maps cleanly onto a Symfony-backed custom FieldType, and doing it now is cheaper than doing it after the legacy kernel is removed.
• Extension points are edits, not hooks. There is no event system for the datatype itself; treat any change as a local fork and note it in a PATCHES.md so future you (or a successor) can rebase on a fork when the upstream repo inevitably goes stale.