Product Decisions This Supports
- Maintain vs. replatform for a legacy eZ Publish 5 estate. This bundle is a symptom-level fix for one custom datatype (
eZobjectRelationListPlus) on a platform that vendors stopped shipping years ago. If it appears in your dependency tree, the real decision on the table is whether to keep patching content-model edge cases or fund a migration off eZ5.
- Content model inventory and migration scoping. Its presence tells you the legacy schema contains a non-standard relation-list datatype. That is a migration cost signal: relation lists typically carry editorial relationships (related articles, product cross-links, tag-like groupings) that need re-modeling in the target CMS. Use this as an input to estimate migration effort and to flag content types for manual review.
- Release-gating for a maintenance or security upgrade. If a platform patch, PHP version bump, or Symfony upgrade is blocked on this datatype, adopting or vendoring the fix becomes a tactical unblocker — a cost-of-delay calculation, not a feature decision.
- Build vs. buy vs. borrow. The realistic options are: borrow this patch, build an internal equivalent, or buy vendor support for the legacy stack. With zero stars, zero dependents, and a single 2016 release, "borrow" means taking on ownership — there is no community to lean on.
- Roadmap sequencing. At best this buys time on the current platform. It should sit in a "keep the lights on" bucket with an explicit expiry date tied to the replatforming roadmap, never in a forward-looking feature plan.
- Technical asset risk register. Abandoned third-party code with no maintainer is an audit and procurement item. Capture it so future architecture reviews and security questionnaires have an answer.
When to Consider This Package
Consider it only when all of the following hold:
- You operate eZ Publish 5.x in production and already use the
eZobjectRelationListPlus datatype in live content.
- A specific upgrade or fix is blocked because that datatype is broken on the eZ5 stack.
- The alternative — re-modeling affected content or expediting the migration — is materially more expensive in the next one to two quarters.
- You are prepared to fork, vendor, pin, and own the code: read it, test it against your data, and carry it internally. Treat it as a code snippet, not a dependency.
- The blast radius is contained: a small number of content classes, a bounded set of editorial workflows, and rollback is straightforward.
Look elsewhere — or skip it entirely — when:
- You are greenfield, or already on eZ Platform / Ibexa DXP. There is no reason to import a 2016 patch into a modern stack.
- You do not actually use this datatype. Nothing here applies.
- You need vendor support, an SLA, security response, or compatibility with current PHP and Symfony versions. The last release was March 2016; assume none of that exists.
- You are pre-replatforming and can absorb the content re-modeling now. Doing the migration work is usually cheaper than carrying an unmaintained patch through another upgrade cycle.
- The fix would become load-bearing for a large content set. Concentration risk on an unowned package is not worth it.
How to Pitch It (Stakeholders)
For executives: This is a small, non-strategic patch for a custom content type on our legacy eZ Publish 5 platform. It is not an investment in new capability — it is a short-term unblocker that lets a maintenance release ship without a content re-modeling project first. The honest framing is cost avoidance with an expiry date: it defers a few weeks of migration work, it does not remove it. The package has no active maintainer, no community adoption, and no release since 2016, so we would take ownership of the code ourselves. Recommendation: approve only as a time-boxed measure tied to the replatforming roadmap, with a named internal owner and a review date.
For engineering: Treat this as a vendored patch, not a Composer dependency you trust. Fork it into our repo, pin the version, add a smoke test that exercises the datatype against representative content, and document exactly which content classes depend on it. Assume zero upstream support: any bug is ours. Keep the change surface minimal so it can be dropped cleanly when the migration lands, and log it in the technical debt register with an owner and a target removal milestone.
For the wider business: No customer-facing change and no new feature is being promised here. The value is continuity — editorial workflows keep working and we avoid an unplanned content migration this quarter. The moment the migration is funded, this package goes away.