- Can I use mrk-te/ibexa-migration-bundle2 in a Laravel application?
- No. It is a Symfony bundle that extends Symfony's Bundle class and depends on Ibexa DXP 5 content repository APIs such as ibexa/content, ibexa/core, and Field Type services. Installing it in Laravel would mean standing up an Ibexa kernel alongside your app, which is not a realistic integration path. For Laravel you need a Laravel-native migration or seeding approach instead.
- How do I install mrk-te/ibexa-migration-bundle2 in an Ibexa DXP 5 project?
- Require it with Composer, register the bundle in config/bundles.php, and configure your migration paths. You then generate and run migrations using the bundle's ibexa:migration console commands. Before planning around it, verify it installs cleanly against your current Ibexa 5 skeleton, since the package has zero dependents and almost no public validation.
- What Laravel versions does this package support?
- None. There is no Laravel support, no service provider, and no facade; the package targets Ibexa DXP 5 on Symfony 6/7 with PHP 8.2+. If your project is a Laravel application, end the evaluation here.
- What kinds of data can I migrate with this bundle?
- Its versioned migration scripts cover content types, content items, roles, and other Ibexa repository data. You write migration files that map content type definitions, Field Type values, relations, locations, URL aliases, and object states, then run them consistently across environments. The migration files themselves are usually the bulk of the work, largely independent of which migration bundle you pick.
- Is the GPL-2.0 license a problem for a commercial Ibexa project?
- Likely yes, and this is the highest-probability blocker. The bundle inherits GPL-2.0 from the original Kaliop eZ-Migration Bundle, and most enterprise legal teams will either reject it as a runtime dependency or require it confined to dev/CI tooling that never ships to production. Get legal sign-off before any engineering spend.
- Does this bundle work with Ibexa 3.3 or 4.x?
- It targets Ibexa DXP 5, and the underlying repository API and Field Type namespaces shifted across major versions. There is no guarantee it works on 3.3 or 4.x, so check compatibility explicitly rather than assuming. Even on Ibexa 5, budget for API drift across minor releases because the content repository is not a stable public contract.
- How does this compare to the Kaliop eZ-Migration Bundle?
- It is a direct port of the long-standing Kaliop bundle, which was the de facto standard for scripted content migration in the eZ/Ibexa ecosystem for about a decade. The mental model carries over unchanged: YAML migration files plus a migrate CLI command. The real difference is maturity, since the original has years of field use while this port has one star and zero dependents.
- Is it production-ready and actively maintained?
- Treat it as early-adopter territory. It has a single maintainer, one star, zero dependents, and no community test surface, so you will be the one discovering edge cases. The recent release date suggests active maintenance today, but that commitment is almost certainly tied to one agency's own client work. Plan for an internal fork or a support arrangement from day one.
- Can I roll back a migration if something goes wrong?
- Assume migrations are one-way unless you verify otherwise, because the bundle is oriented around running versioned scripts forward and there is no documented rollback story. Test every migration against a staging copy of the content repository first. Take a database and repository snapshot before running anything in production.
- Does it handle Solr or Elasticsearch reindexing and URL alias regeneration?
- Do not assume it does. Search reindexing and legacy URL alias regeneration are typically your responsibility on top of the content migration itself. Confirm explicitly which Field Types, Page Builder blocks, and Commerce objects are in scope, and whether custom Field Types are covered, since the Kaliop original had gaps there and a fresh port likely has more.