Ezobject Relationlistplus Bundle Laravel Package

Getting Started

This is not a Laravel package — it is a Symfony bundle for eZ Publish 5.x (the transitional "legacy + new kernel" stack). Its only job is to register the legacy eZobjectRelationListPlus datatype with the eZ5 kernel so content classes that use it continue to work. Treat it as a compatibility shim, not a feature library.

Minimal steps:

1. Confirm you actually need it. Grep your content class definitions (ezcontentclass_attribute table, data_type_string column) for ezobjectrelationlistplus. If nothing uses it, do not install it — the standard ezobjectrelationlist covers most cases.
2. Install into the eZ5 project root:

   composer require xrow/ezobject-relationlistplus-bundle
   

3. Register the bundle in ezpublish/EzPublishKernel.php:

   public function registerBundles()
   {
       $bundles = parent::registerBundles();
       $bundles[] = new xrow\EzObjectRelationListPlusBundle\xrowEzObjectRelationListPlusBundle();
       return $bundles;
   }
   

4. Ensure the legacy extension is present and active. The bundle only wires things up; the actual datatype PHP class must live under extension/ezobjectrelationlistplus/ and be listed in settings/override/site.ini.append.php → [ExtensionSettings] ActiveExtensions[]=ezobjectrelationlistplus. Check the repo's Resources/ and extension/ folders first — that is where the real logic (if any) is.
5. Regenerate autoloads and clear both caches (both are required, always):

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

First use case: an editor adds a relation of type Object relation list plus to a content object; you verify it appears in both the legacy admin and the new-kernel front end, then render it in Twig via a legacy template override (see below).

Implementation Patterns

Reading the attribute from the new kernel. $content->getFieldValue('my_attribute') returns a legacy-backed value object, not a plain array. Iterate the wrapped content object attribute:

$field = $content->getField('my_attribute');
$attr  = $field->value;                    // eZContentObjectAttribute-backed
if ($attr instanceof \eZContentObjectAttribute) {
    foreach ($attr->content()->attribute('object_list') as $relation) {
        $object = \eZContentObject::fetch($relation['contentobject_id']);
    }
}

Rendering in Twig. The new kernel does not render legacy datatype templates for you. Provide a legacy template at extension/ezobjectrelationlistplus/design/standard/templates/content/datatype/view/ezobjectrelationlistplus.tpl (and a .../edit/ variant), or override the content view template to delegate with {{ ez_legacy_render('content/datatype/view/ezobjectrelationlistplus.tpl', {...}) }}. Whichever path you take, the attribute must be rendered by the legacy kernel — that is the whole point of the bundle.

Content class setup. Create the attribute in the legacy admin (Setup → Classes), identifier ezobjectrelationlistplus. Because the datatype is a legacy one, it will not appear in the eZ Platform class editor; that is expected and is not a bug in the bundle.

Daily workflow. Keep this bundle in the legacy group of your kernel registration, loaded after EzPublishLegacyBundle and after you have registered any project override extensions. When you modify templates or the datatype class, the legacy cache must be purged — build this into a deploy script rather than relying on developers to remember:

php ezpublish/console ezpublish:legacy:script bin/php/ezpgenerateautoloads.php
php bin/php/ezcache.php --clear-tag=template --purge
php bin/php/ezcache.php --clear-tag=content --purge

Integration tip. If your site mixes standard and "plus" relation lists, build a small Twig helper that normalises both into an array of {id, object} so templates do not need to branch on datatype. Otherwise every template override has to special-case the legacy attribute object.

Gotchas and Tips

• Dead since 2016. No releases for eZ Platform 2/3/Ibexa. The new-kernel datatype registration API changed; do not expect this to install or boot on anything beyond eZ Publish 5.x. If you are on eZ Platform 2+, fork the datatype into a proper FieldType with a paired legacy storage gateway instead.
• PHP version. Legacy-era code frequently uses each(), create_function(), or other constructs removed in PHP 7.2+. Pin PHP or patch the datatype class; failures show up as generic 500s in the legacy stack, not as clear errors.
• Two caches, always. Symfony's cache and the legacy var/cache / var/ezpublish caches are independent. A "datatype not found" or "no template for attribute" error after install is almost always a stale legacy cache or un-regenerated autoloads.
• Identifier mismatch. ezobjectrelationlistplus (this package) is not ezobjectrelationlist (core). Renaming an attribute's type after content exists corrupts the stored data — migrate data explicitly.
• Missing legacy extension. Many copies of this bundle contain only the Symfony registration and expect the actual extension to ship separately. If extension/ezobjectrelationlistplus/ does not exist, the bundle is inert and you will see "unknown datatype" errors. Verify before debugging anything else.
• 0 stars / 0 dependents. No community testing. Vendor it ("repositories": [{"type": "vcs", ...}]) or commit it into your repo so an upstream deletion cannot break your build. Add a smoke test that fetches a content object with the attribute and asserts the object list is non-empty.
• Permissions and reverse relations. The datatype writes to the standard relation tables, so ezcontentobject_link permissions and the "reverse related objects" cache apply as usual. If relations vanish, check ezcontentobject_link directly before assuming the bundle is broken.
• Extension points. Override the datatype class by placing a higher-priority project extension in ActiveExtensions; override rendering via design/<your_design>/templates/content/datatype/view/. Hooks (pre_fetch, post_fetch) in a legacy extension remain the cleanest place to post-process relation lists — do not patch the bundle in place.