- Can I install kunicmarko/sonata-importer-bundle in a Laravel application?
- No. This is a Symfony bundle that depends on Sonata Admin, Symfony's DI container, bundle registration and the event system, so there is no surface area it can hook into inside an Illuminate application. Composer may resolve it, but nothing in Laravel will call it, and you would have to stand up a parallel Symfony kernel for one workflow. Use it as a reference design for an import pipeline, not as a dependency.
- Which PHP, Symfony and Sonata Admin versions does sonata-importer-bundle support?
- The last tagged release dates from 2020-10-18, so expect PHP 7.x constraints, Symfony 3.4, 4.x or 5.x, and Sonata Admin 3.x. Read the composer.json on the tagged release before doing anything else, because any one of those pinned ranges is a blocking modernization cost rather than a footnote. Running it on PHP 8.2 with Symfony 6 or 7 requires a fork plus dependency-constraint surgery first.
- Is kunicmarko/sonata-importer-bundle still maintained?
- No, the repository is archived and there is no maintainer response path. It has roughly 4 stars and zero dependents, so there is no ecosystem validation, no issue history to mine for failure modes and no third-party forks to fall back on. No security advisories will ever be issued for it, and its transitive dependencies such as PhpSpreadsheet, league/csv and Symfony components will drift out of the pinned ranges over time.
- How do I install and register sonata-importer-bundle in a Symfony project with Sonata Admin?
- On a genuine Symfony plus Sonata Admin estate it is roughly a half-day job: add the package with Composer, register the bundle in bundles.php or the kernel, then define your importer service. You then wire a reader for the uploaded file and a writer that persists to Doctrine entities, and expose the whole thing as a Sonata admin action or extension. Pin the fork to your PHP and Symfony versions and vendor it through a VCS repository entry if you take ownership.
- How do I define import mappings and field transformations in Sonata Admin?
- The bundle's premise is that you configure the mapping between incoming file columns and Doctrine entity fields through the Sonata admin interface rather than writing a one-off import script for each entity. Each importer combines a reader, a column-to-field mapping, optional value transformations and a writer that persists the hydrated entities. Because these are ordinary Symfony services, the mapping and transformation logic lives in your container configuration and is testable outside the admin UI.
- What file formats can the Sonata importer bundle read, CSV or XLS?
- The bundle abstracts the read step behind a reader service, and real-world usage pairs it with league/csv for CSV or PhpSpreadsheet for XLS and XLSX. Format support therefore depends on which reader you wire in, not on the bundle itself. That abstraction is the most portable idea in the package and transfers cleanly to any stack.
- What is a Laravel alternative to sonata-importer-bundle for importing spreadsheets into Eloquent models?
- Reimplement the pattern natively: maatwebsite/excel or league/csv for parsing, a FormRequest-style import request object for validation, a queued job for execution, and a Filament, Nova or Livewire action for the UI trigger. The bundle's decomposition of reader, column mapping, validator, transactional writer and admin trigger maps directly onto that stack. An import flow is typically a few hundred lines, so the domain logic is not the expensive part; the Sonata wiring is, and you do not have Sonata.
- How much work is it to fork sonata-importer-bundle for PHP 8.2 and Symfony 6 or 7?
- Expect dependency-constraint surgery before the first line of business logic: bumping the PHP, Symfony and Sonata Admin ranges, resolving the Sonata Admin 3 to 4 or 5 API differences, and getting the existing test suite green. Fork-and-modernize is only justified if you already run Sonata and the admin-action plumbing is the genuinely expensive part. Otherwise build the import natively and carry over only the conceptual design.
- Can sonata-importer-bundle run imports asynchronously through a queue or worker?
- There is no built-in queueing; imports are triggered from a Sonata admin action and run inside the admin HTTP request. For large files or long-running imports you should dispatch a Symfony Messenger message from that action and perform the read, map and write inside a worker. Decide up front whether you need partial-failure semantics, idempotency and dry-run or rollback support, because the package does not provide them.
- What license does sonata-importer-bundle use, and can I vendor a fork with Composer?
- It is MIT licensed, which is permissive and allows forking, modifying and vendoring. You can point Composer at your own fork using a VCS repository entry and pin it to your PHP and Symfony versions. The license is the one unambiguous positive here, but taking a fork also means owning ongoing dependency upkeep, so assign a Symfony-fluent engineer with capacity for it.