Fieldtype Matrix Laravel Package

Product Decisions This Supports

• Content modeling for grid/table data inside Ibexa DXP. This field type lets editors enter structured row/column data (pricing tables, spec sheets, size charts, rate cards, seating/aisle maps, comparison matrices) as a first-class content field rather than free-form HTML or a bloated block of embedded JSON. The decision it unblocks is "do we model this content natively in the CMS, or ship it as a custom content type / custom editor UI?"
• Build vs. buy on a recurring pattern. Matrix-shaped content shows up in nearly every B2B/industrial/travel/retail content model. Adopting an official Ibexa field type is the "buy" (or rather "assemble from vendor parts") option versus 2–6 weeks of custom field-type development plus ongoing maintenance.
• Editor autonomy vs. developer dependency. Shipping a matrix field type pushes table authoring to content teams instead of routing every pricing-table change through engineering — a measurable reduction in content-change lead time.
• Roadmap scoping for Ibexa-based products. If the product roadmap includes catalogs, technical documentation, or comparison experiences, this is a candidate dependency to evaluate at architecture time, not mid-sprint.
• Upgrade and lock-in planning. Because it is versioned and maintained by Ibexa alongside the DXP release train, adopting it ties your content model to Ibexa's upgrade cadence — a roadmap constraint worth naming explicitly.

When to Consider This Package

Consider it when all of the following hold:

• You are already running Ibexa DXP or Ibexa Open Source, and the team is comfortable with the Ibexa field-type/content-model extension model. This is not a general-purpose Laravel package; it is an Ibexa bundle and delivers near-zero value outside that stack.
• You hold a valid Ibexa DXP subscription, so the Ibexa Business Use License (BUL) path applies and the GPL-2.0 copyleft branch is not your operative license.
• You need editor-managed, structured row/column content that must be queryable/rendered through the standard Ibexa templating and API layers — not a one-off static table you could hard-code in a template.
• You want vendor-supported components over community packages, and you accept that support flows through your Ibexa contract rather than GitHub issues.
• You are prepared to pin and test on DXP upgrades, since field types touch storage and content-model definitions.

Look elsewhere — or build a thin custom field type — when:

• You are not on Ibexa. For Laravel/Symfony projects generally, use a table/grid field in your own admin stack (e.g., a repeatable-block or JSON column with a custom form widget). This package offers nothing here.
• Licensing is unresolved. The dual license is the biggest gating item. NOASSERTION on the repository plus a GPL-2.0 option means that without a DXP subscription, distributing a proprietary product that includes this code is a legal question for counsel, not a PM call.
• You need community traction or third-party support. Four stars and zero dependents is a strong signal: this is a vendor carve-out repo, not an ecosystem project. Assume no Stack Overflow answers, no third-party tutorials, no community bug fixes.
• You need heavy guarantees on docs, tests, or a public changelog. Maturity signals here are limited to a README and release tags. Treat it as "works, but verify" — demand a spike/POC and read the actual field-type source before committing.
• The data is trivial. A two-column, five-row table does not justify a new field type; a rich-text table or a simple block will do. Adopt this only where matrices recur and editors genuinely need structure.
• You need portability across CMS platforms. Matrix content stored in an Ibexa-specific field type is migration debt if you ever leave the platform.

How to Pitch It (Stakeholders)

For executives: Ibexa ships an officially maintained field type that lets our editors build structured tables — pricing grids, spec sheets, comparison matrices — directly in the CMS, without engineering involvement per change. It is part of the Ibexa product family, so it is covered by the DXP subscription we already pay for and comes with the same upgrade and support path as the rest of the platform. The business case is straightforward: fewer engineering tickets for content updates, faster time-to-publish for catalog-style pages, and no bespoke component to maintain. The caution is equally simple — its public footprint is essentially zero (a handful of stars, no external users), so it is a vendor bet, not a community bet; our confidence comes from the Ibexa contract, and we should confirm licensing in writing before it reaches production.

For engineering: This is an Ibexa field-type bundle, not a Laravel package — relevance is contingent on us being on DXP. It stores matrix data as a proper field type, so it flows through the standard ContentType/FieldType APIs, templates, and search rather than being smuggled in as HTML or JSON blobs. It is dual-licensed under the Ibexa BUL (requires a valid DXP subscription) and GPL-2.0; the repo's license detection returns NOASSERTION, so get the applicable license confirmed before we build a content model on it. Signals are thin — 4 stars, 0 dependents, README-plus-releases-only maturity — so plan a timeboxed spike: install it, define a matrix content type, render it in a template, confirm upgrade behavior and data migration, and check the release cadence against our DXP version. If the spike is clean, it replaces a custom field type we would otherwise own forever; if not, we fall back to a small in-house field type with the same interface so the content model stays portable.