- How do I install alengo/sulu-contact-account-extra-bundle?
- Install it with composer require alengo/sulu-contact-account-extra-bundle, then register AlengoContactAccountExtraBundle in config/bundles.php. Import the bundle's routing_admin_api.yaml in config/routes/sulu_admin.yaml under the /admin/api prefix. Finally run bin/adminconsole doctrine:migrations:diff and doctrine:migrations:migrate to add the additionalData JSON column. No further configuration is required for a standard setup.
- Is this a Laravel package or a Sulu CMS bundle?
- It is a Sulu CMS 3.x bundle built on Symfony, not a Laravel package. There are no service providers, Eloquent models, or Laravel-specific configuration; integration happens through Sulu's bundle, admin resource, and form systems. It is still installable via Composer, but it belongs in a Sulu/Symfony application rather than a Laravel one.
- Which Sulu, Symfony, and PHP versions are supported?
- The requirements are PHP 8.2+, Sulu CMS ~3.0, and Symfony 7.x according to the README. The 1.1.0 release adds Symfony 8.1 support, widening the platform range for greenfield projects. Because the release notes do not explicitly confirm that Symfony 7.x remains supported, check the composer.json constraint before assuming the upgrade is non-breaking. Also verify that your pinned Sulu 3.x release is itself Symfony 8 compatible before moving the whole stack.
- Do I need extra database tables to store the custom fields?
- No. Custom field values are stored in a single additionalData JSON column added to Sulu's co_contacts and co_accounts tables, so there are no extra tables or joins. This keeps schema management simple but means structured filtering and reporting on those values is limited. The migration is low risk but still requires a short maintenance window, so test it and a rollback path in staging first.
- How do I define the fields shown in the Additional Data tab?
- You define them yourself with Sulu form XML files, typically config/forms/contact_additional_data.xml and config/forms/account_additional_data.xml. The bundle intentionally ships no default forms, so the project fully controls field definitions, labels, and types. The expected form and resource keys are configurable via alengo_contact_account_extra.contact.form_key and the equivalent account settings if you prefer different names.
- What REST endpoints does the bundle provide?
- It exposes a generic GET and PUT endpoint for the additional data of contacts and accounts, imported under the /admin/api prefix from the bundle's routing_admin_api.yaml. The endpoints serialize the entire JSON blob rather than individual fields, which keeps the API stable as your form evolves. There are no additional routes, nested resources, or per-field endpoints, so complex validation must live in your form definitions.
- Do I have to create my own Contact and Account entities?
- No. The bundle ships built-in concrete Contact and Account entities that extend Sulu's base classes and add the additionalData field, and they are auto-registered through PrependExtensionInterface. Sulu contact objects and admin resources are configured the same way, so basic use cases need no boilerplate. If you already have project entities, point the entity_class configuration at them instead.
- Can I query or filter contacts by values inside the additionalData JSON?
- Only indirectly. Because the data lives in a JSON column, filtering requires database-specific JSON functions and there is no query layer or indexed access provided by the bundle. This design suits projects where custom fields are mainly displayed and edited rather than searched. If you need heavy filtering or reporting on those fields, promote them to real columns in your own entity.
- How does validation work for the custom fields?
- Validation is delegated entirely to the form XML you write, so constraints are only as consistent as your form definitions. The PUT endpoint accepts and stores the full JSON blob, so there is no built-in nested validation or per-field type enforcement at the API layer. Standardize your form constraints across contacts and accounts if data integrity matters to you.
- Is this bundle actively maintained and safe for production?
- The project has two releases, with 1.1.0 adding Symfony 8.1 support, which corroborates active maintenance at a modest level. It still has no stars, dependents, or documented adoption, so real-world validation is limited and long-term stability is unproven. Review the code, pin a version, and test the full composer update with all dependencies in a staging branch before relying on it in production.