Event Bundle Laravel Package

Getting Started

First, a reality check that shapes everything below: this is not a Laravel package. xrow/event-bundle is a Symfony 2.x bundle for eZ Publish 5 (the eZ5 stack that wraps the legacy eZ kernel), and its entire purpose is to ship a custom ezpublishevent datatype plus the fix-ups that datatype needs to keep working after upgrades. It has no service provider, no facade, no config file Laravel reads, and its classes extend eZ\Publish\Core\FieldType\* / legacy kernel datatype interfaces that simply don't exist in a Laravel app. If you are looking for a Laravel publishing/event package, stop here — this is not it.

Assuming you actually maintain an eZ Publish 5 site (the only context where "leveraging" this package makes sense), the minimal path is:

1. Read the bundle root first: look for a Datatypes/ (or eZ/Publish/FieldType/) directory containing the ezpublishevent field type, the legacy datatypes/ezpublishevent kernel classes, and the DependencyInjection/ extension. That layout tells you where the fix lives — usually the value/definition classes and the legacy type registration.
2. Require it alongside your eZ Publish 5 composer project (composer require xrow/event-bundle), pinning to whatever branch matches your eZ version. Check the composer.json for a symfony/* or ezsystems/ezpublish-kernel constraint; that constraint is your real compatibility contract.
3. Register the bundle in app/AppKernel.php and the datatype in ezpublish/config/ezpublish.yml under ezpublish.fieldType, plus the legacy registration in override.ini / ezinfo.php if the type needs to resolve in the legacy admin.
4. Create a content class that uses the ezpublishevent attribute and confirm it saves, displays, and re-reads without a fatal in var/log/ezpublish.log. That round-trip is your first use case and the whole point of the package: it makes the custom datatype stop breaking on eZ5.

Implementation Patterns

There is no Laravel-style "install and use the facade" workflow. Day-to-day use falls into three patterns:

• Datatype registration as configuration. The bundle's job is to make ezpublishevent resolvable. You wire it in ezpublish.yml and, where the legacy kernel still looks, in INI overrides. Treat the bundle as a dependency of your content model, not of your application code — you rarely call into its classes directly.
• Content-class authoring. Add an ezpublishevent attribute to a content class, then store event data (publish trigger / event descriptor, depending on how the type is implemented) through the public API (ContentService::createContent / updateContent with a FieldValue). In templates, render via ez_render_field or the legacy content/attribute fetch, and pull the value through the field type's toHash() if you need it in Twig.
• Publish-hook integration. As the name implies, the type is usually consumed around publish transitions. If your project already uses Symfony event subscribers on ezpublish.content events (ContentService::publishContent listeners) or legacy workflow events, that is where you observe/validate this datatype. Keep integration in your own subscribers rather than editing the bundle, so upstream updates remain mergeable.

Integration tips: keep a pinned eZ5 project skeleton, install bundle edits via composer (not by copying classes into extension/), and add a smoke test that creates/updates content carrying the datatype so regressions surface before deploy.

Gotchas and Tips

• Version drift is the main failure mode. The package exists to "fix" a datatype for eZ5; the fix is only valid for specific eZ/Symfony versions. A constraint mismatch shows up as Class not found or a kernel datatype error at boot, not a clean Composer complaint. Match the branch to your eZ minor version before debugging anything else.
• It is not a Laravel package — don't try to make it one. No service provider, no config publishing, no Illuminate dependencies. Any attempt to php artisan vendor:publish will find nothing. The Symfony bundle and eZ Publish integration are the only supported surfaces.
• Two registries to keep in sync. Newer eZ5 resolves field types through ezpublish.yml; the legacy admin/kernel still reads override.ini/content.ini style config. If the type works on the front end but not in the admin, the legacy INI registration is almost always the missing half.
• Debug in var/log/ezpublish.log and Symfony's app/logs/dev.log, not with dd()/dump-style debugging — the boot/kernel errors that matter happen before any of your app code runs.
• Legacy datatype internals are unforgiving. Value/definition classes usually need concrete toHash(), fromHash(), and legacy store/restore equivalents; a missing method surfaces as a silent empty value rather than an exception. When data "disappears" after edit, check both hash and store paths.
• Extension point is your own bundle, not theirs. Customize rendering, validation, or publish behavior with subscribers, Twig helpers, and template overrides in your project; fork the datatype only if you must, and then vendor it under a different name so composer update doesn't clobber your changes.
• Zero ecosystem / no support signal. With no stars and no dependents, expect no community troubleshooting — keep the source in your vendor dir and treat every upgrade as a code review of the diff.