Phpcr Migrations Bundle Laravel Package

Product Decisions This Supports

• Content model evolution on PHPCR-backed platforms. This bundle wires the phpcr/phpcr-migrations library into Symfony's DI/console, so it directly supports the decision of how we ship changes to a content repository (node types, properties, paths, fixtures, backfills) across dev, staging, and production. It turns "we need to change the CMS content model" into a repeatable, versioned release artifact rather than a manual admin-UI chore.
• Build vs. buy for content migrations. Without this, the realistic alternative is bespoke one-off PHP scripts or manual editorial steps. Adopting the bundle is the "buy/assemble" path: it standardizes the migration runner, ordering, and console ergonomics. The build decision is really "do we own a migration framework or delegate to a maintained MIT library plus a thin Symfony integration?"
• Roadmap sequencing for CMS/content features. If the roadmap includes content-type additions, taxonomy changes, field renames, or bulk data normalization, this package is the delivery mechanism that de-risks those releases. It makes content schema changes schedulable and reversible in the same way DB migrations are, which affects how confidently we can commit to content-facing dates.
• Platform selection / upgrade strategy. It is only relevant if the stack is PHPCR (most commonly Sulu CMS on Jackalope). That makes it a supporting input to a bigger decision — whether to stay on PHPCR-based content tooling or move toward a Doctrine ORM/DBAL or headless-API model where doctrine/migrations is the norm.
• Environment parity and release safety. Supports decisions about deploy pipelines: migrations become a named, ordered step in CI/CD, giving a rollback/audit story for content changes that otherwise live in tribal knowledge.

When to Consider This Package

Consider it when:

• You run a Symfony application whose content lives in a PHPCR repository — in practice Sulu CMS or a custom Jackalope/Doctrine PHPCR ODM setup.
• You already accept the Doctrine-migrations mental model (versioned migration classes, migrate/status/rollback-style commands) and want the same for content nodes.
• Content changes are frequent or risky enough that manual editorial steps are a release-blocking liability — multi-environment promotion, auditability, or repeatable seeding matters.
• You want the smallest possible glue: this is a thin integration bundle, so the blast radius of adoption is low and it can be introduced alongside existing tooling.
• You need a permissively licensed (MIT) dependency with a 2024 release, and you are willing to vendor/pin it.

Look elsewhere when:

• Your data is in a relational store — use doctrine/doctrine-migrations-bundle; this package solves a different problem.
• You are not on PHPCR at all; there is no partial benefit here.
• You require broad community support, security responsiveness, or a documented LTS. Ten stars and an unknown/undisclosed repository is a genuine due-diligence red flag: expect to read the source, pin versions, and assume you may need to fork.
• Your team has no PHPCR expertise. The library assumes fluency in node paths, workspaces, and PHPCR semantics; the bundle does not abstract that away.
• You need rich, first-class rollback or dry-run guarantees — verify command coverage and semantics against your requirements before committing; don't assume parity with mature DB migration tooling.

Due diligence before adoption: confirm the transitive state of phpcr/phpcr-migrations, check the actual repository/homepage (listed as unknown), inspect the bundle's service wiring and console commands, and run a proof-of-concept migration against a disposable workspace.

How to Pitch It (Stakeholders)

For executives (one paragraph): Our content platform stores data in a PHP Content Repository, which means content-model changes — new fields, renamed properties, bulk data fixes — are currently applied by hand and are hard to repeat or audit. This Symfony bundle is a small, MIT-licensed adapter that lets us treat those content changes as versioned, ordered, code-reviewed migrations executed by a console command, the same way we already manage database migrations. The business value is reduced release risk and less engineering time spent on manual CMS surgery. The trade-off is maturity: the package has a very small community footprint and an opaque repository, so I recommend a time-boxed pilot with version pinning and a documented fork/exit plan rather than a broad rollout.

For engineering leads: It's a thin Symfony integration over phpcr/phpcr-migrations — service definitions plus console commands, nothing structural. If you already know Doctrine Migrations, the workflow is familiar: write a migration class, register it, run it per environment. Concerns to validate in the spike: (1) low external adoption — we should own the upgrade path and be ready to vendor or fork; (2) the underlying migrations library's feature set and command semantics, especially around rollback and status reporting; (3) behavior across multiple PHPCR workspaces and in CI with ephemeral repositories. Keep it isolated behind the console interface so swapping it out is a contained change.

For the product owner: Adopting it unblocks content-heavy roadmap items — new content types, metadata backfills, structural cleanups — by making them shippable in a normal release train instead of requiring a maintenance window and manual editorial work.