- Is jarjobs/sonatadtomodelmanager a Laravel package?
- No. Despite how it is sometimes described, this is a Symfony bundle built for Sonata Admin and Doctrine that hooks the Sonata model-manager lifecycle. Laravel has no Sonata Admin, no ModelManagerInterface and no equivalent form-to-entity binding contract, so there is nothing for it to integrate with in a Laravel codebase. Rule it out before spending any evaluation effort on a Laravel service.
- Can I install it in a Laravel app with Composer?
- Composer may resolve the requirement, but the package ships no Laravel service provider, facade, config file or Eloquent adapter. Its persistence path depends on Sonata Admin and Doctrine, neither of which exists in a standard Laravel application. Installing it would only add an unused dependency and extra surface area to your lockfile.
- What does this package actually do in a Symfony application?
- It inserts a DTO between the Sonata Admin form and the Doctrine entity, so the admin form binds to the DTO instead of mutating the model directly, and a model manager then persists it. That pattern is well established — Symfony form data mappers and API Platform input DTOs do the same thing. It solves real problems such as validation isolation, partial updates, multi-entity forms and protecting entities from form-shaped mutation.
- Which Symfony, Sonata Admin, PHP and Doctrine versions are supported?
- There is no published compatibility matrix, so read composer.json before anything else. If the sonata-project/admin-bundle constraint is ^3.x, expect to stay there, because ModelManagerInterface signatures changed materially in 4.x. Treat every version claim as unverified until a CI matrix proves it on your exact stack.
- How do I install and configure it?
- No verified installation guide is available, so the expected steps are a Composer require, bundle registration, and wiring the manager per admin via configuration such as manager_type or model_manager. The critical unknown is the hook mechanism: whether it decorates ModelManagerInterface, uses a compiler pass, or requires per-admin subclassing. Confirm that before committing to any setup estimate.
- Does it work with Doctrine ODM and MongoDB, or only ORM?
- This is not documented. Embedded documents, collection fields and ODM support are all unstated, and the package is described only in model-manager terms. Assume Doctrine ORM only until you have verified otherwise on a real mapping.
- How are validation failures, file uploads and nested admin forms handled?
- These behaviours are not publicly evidenced, and they are the real risk areas for any DTO-in-the-middle approach. On validation failure the DTO must survive the form re-render, or users lose their input. Pilot a single low-risk admin with no file uploads and no nested collections, then test partial updates explicitly before going further.
- Is it production-ready and actively maintained?
- There is no adoption evidence: zero stars, zero dependents, a single maintainer and an internal-extraction-looking namespace, with license, test coverage, CI status and release history all unknown. Abandonment should be treated as the base case. If you do adopt it, plan to fork and vendor internally with a named owner and a written exit plan.
- What are the alternatives?
- Implement the same pattern yourself with a Symfony form data mapper plus a plain DTO class; it is a few hundred lines you fully own. API Platform input DTOs are prior art for the identical idea. If Sonata is only a handful of back-office screens in your estate, the in-house option clearly beats adding a third-party bundle.
- What is the recommended way to evaluate it?
- Create a spike branch pinned to your exact Symfony, Sonata Admin, PHP and Doctrine versions and convert one simple CRUD admin to the DTO flow. Then hand-roll a DTO and data mapper on a second admin and compare the diffs. That comparison is the decisive test: adopt, fork and own, reimplement in-house, or drop.