xrow/field-types-bundle
xrow/field-types-bundle offers reusable field type definitions for PHP applications, helping developers register and manage custom fields with less boilerplate. Adoption and documentation are limited, so evaluate fit carefully before use.
Before writing a single line of integration code, confirm what you are actually installing. xrow/field-types-bundle is a Symfony bundle for eZ Publish / eZ Platform, not a Laravel package. There is no ServiceProvider, no Facade, no config/*.php to publish, and no Artisan command. Composer will happily install it into vendor/, but Laravel's container will never instantiate the bundle class, so nothing happens at runtime.
The first place to look is the package's own composer.json — check type (symfony-bundle), the require block (it will pull in old ezsystems/ezpublish-kernel style dependencies), and the autoload PSR-0/PSR-4 mapping. Then read the bundle class under src/ (historically lowercase, e.g. xrowFieldTypesBundle) and Resources/config/, which is where the datatype service wiring lives. That is the entirety of the package.
Your first "use case" as a Laravel developer is almost never a greenfield one. It is: you have inherited a legacy eZ Platform codebase (Symfony 2/3 era) that already lists this bundle, or you are evaluating whether it belongs in a new app. In the second case the answer is no — do not add it. If you need custom field types in Laravel, reach for a JSON/EAV column with an Eloquent cast, spatie/laravel-schemaless-attributes, or a dedicated form-builder package. There is no bridging story from eZ datatypes to Laravel.
In its native habitat (eZ Platform): the bundle fixes custom xrow datatypes exposed by various xrow extensions. The day-to-day pattern is registration, not coding — enable it in app/AppKernel.php (new xrow\FieldTypesBundle\xrowFieldTypesBundle()), make sure the corresponding xrow extension(s) and content classes exist, then clear caches and regenerate legacy autoloads (php bin/php/ezpgenerateautoloads.php, ezcache). After that the datatypes render correctly in the admin UI and legacy stack. You rarely touch this bundle's code directly; you extend the underlying datatype classes instead.
In a Laravel app: there is no idiomatic pattern, and that is the honest assessment. The package is inert. Two things you can legitimately do:
composer why xrow/field-types-bundle and grep -r "xrow" across app/, config/, and composer.json. If nothing references it, composer remove it. This is the most common real-world task.app/Support/, but they inherit from eZ kernel types, so you would need to stub or replace those dependencies. This is a multi-day porting exercise, not an integration. Only do it if the field logic itself is the valuable asset.Version-pinning matters either way. The 2017 release targets an EOL Symfony/kernel line; a Symfony 5/6 or Laravel 10/11 app will not boot the bundle. If legacy eZ is genuinely your target, pin it exactly and treat it as frozen.
xrowFieldTypesBundle violates PSR-4 expectations; on case-sensitive filesystems (Linux CI, Docker) autoloading will fail if you "correct" the casing. Leave it.php artisan vendor:publish silently does nothing. No publishes, no migrations, no assets. Don't debug an invisible publish step — there isn't one.composer dump-autoload and php artisan optimize:clear will not register anything. The bundle is dead weight in a Laravel process."repositories": [{"type": "vcs", ...}]) rather than relying on Packagist, and pin the commit.composer.json to require PHP 5.6/7.x-era extensions; modern PHP 8.2+ installs will conflict. Use --ignore-platform-reqs only as a last resort, never in production.bin/console debug:container --tag=ezpublish.fieldType, cache:clear, and check that the legacy settings files reference your xrow extension. Debugging in Laravel: composer show xrow/field-types-bundle — if it's there and unused, delete it.How can I help you explore Laravel packages today?