Fieldtype Richtext Laravel Package

Product Decisions This Supports

• Whether rich text is a first-class content field. ibexa_richtext is the Field Type behind every body-copy surface in Ibexa DXP — articles, landing pages, product descriptions, campaign copy. Adopting or extending it is a content-model decision, not just an editor decision.
• Structured content vs. HTML blobs. It stores formatted text as XML validated against an extensible RelaxNG schema (ezpublish.rng), not HTML. That underwrites multi-channel delivery, content reuse, migration fidelity, and downstream transformation (XML → HTML/AMP/app payloads) rather than markup scraping.
• Build vs. buy on the editor. It bundles CKEditor 5 with Ibexa-authored plugins (custom tags, embedded images and links, table styling, special characters). Choosing it is a decision not to build an editor, schema, validator, and sanitiser in-house.
• Custom-tag / component roadmap. Block and inline custom tags plus siteaccess-aware link creation are the levers for editorial "content components" (CTAs, pull-quotes, product teasers, embeds). This is where editorial-experience differentiation lives, and where roadmap asks should be aimed.
• Multi-site and localization strategy. Siteaccess selection when creating RTE links, plus XML storage, supports decisions about site-tree-aware linking and translated content reuse.
• Security and patch policy. Repeated XSS fixes in custom tags (e.g. IBX-10288) establish rich text as a standing attack surface — supports decisions on sanitiser policy, review gates, and dependency-update cadence.
• Upgrade and support windows. Parallel 4.6 and 5.0 maintenance streams with matched fixes reveal the vendor's supported-version window; use it to plan the DXP upgrade and pick the branch you standardize on.

When to Consider This Package

Consider it when:

• You are already on — or committed to — Ibexa DXP. This is not a standalone library; the README states you install Ibexa DXP to use it. If you're on Ibexa, you don't evaluate it, you govern it.
• You need schema-validated structured rich text: multi-channel publishing, content migration, editorial governance, or downstream transformation.
• You need editorial embeds bound to a content repository — content-item references, images with filters/variants, siteaccess-aware links.
• You require a commercially supported component with a vendor SLA and a predictable release train rather than community-only support.
• Your stack already matches: PHP + Symfony 7.4 LTS on the 5.x line, Encore/TypeScript asset pipeline, CKEditor 5.

Look elsewhere when:

• You are not an Ibexa customer. For a general Laravel app, adopting a DXP to obtain one field type is not defensible; a standalone stack (CKEditor 5, Tiptap/ProseMirror, TinyMCE) plus your own storage is far cheaper.
• You want a drop-in Composer package. No Laravel service provider, no Blade components, no publishable config — it's a DXP-internal bundle with no framework glue.
• License terms don't fit. Dual-licensed under Ibexa BUL v2.4+ (requires a paid subscription) or GPLv2 (copyleft, no warranty). If you cannot accept copyleft and will not buy a subscription, stop. The NOASSERTION license metadata makes legal review mandatory before any use.
• You need community momentum. 6 stars, 0 dependents, and issues tracked in Ibexa's private Jira rather than GitHub mean no public community, no third-party plugin ecosystem, and no grassroots leverage on the roadmap. Budget for vendor-relationship management instead.
• HTML round-tripping is a hard requirement. Storage is XML-only; if consumers expect HTML natively, you own the serializers.
• You cannot verify release provenance. The metadata shows a last release date ahead of normal reporting; confirm version/branch alignment with your DXP release before committing it to a plan.

How to Pitch It (Stakeholders)

For executives: This is not a new purchase — it's a component of the Ibexa DXP subscription you already hold. The real question is whether current rich-text authoring is good enough to keep, or whether editorial experience needs investment. The value story is content operations: one authored body, stored as structured XML, publishes to web, app, and headless consumers without rework. The risk story is equally clear: licensing is subscription-bound (Ibexa BUL) or GPLv2, so treat it as part of DXP renewal rather than a line item; support arrives on a dual 4.6/5.0 cadence, so plan upgrades around the supported branch rather than assuming indefinite maintenance. Its small public footprint and closed issue tracker mean roadmap influence comes through the commercial relationship, and security patches (notably XSS in custom tags) must be tracked as a standing obligation. Recommendation: stay current on the vendor's 5.x branch and fold patch uptake into normal operations.

For engineering: Scope is the ibexa_richtext Field Type — XML storage validated by an extensible RelaxNG schema, a CKEditor 5 front end with Ibexa plugins (custom tags, embeds, tables, links, special characters), and a validator layer shared with custom styles. It is consumed through the DXP meta-package, requires Symfony 7.4 LTS, and uses an Encore/TypeScript build on 5.x; there are no Laravel bindings, so don't plan for one. The extensibility that actually matters: extending ezpublish.rng for custom markup, registering custom tags for editorial components, and using siteaccess-aware link handling for multi-site setups. Your obligations are owning the sanitisation policy for custom tags, pinning to the DXP release train, and reading IBX-numbered release notes for behavioural changes since public issues aren't available. What not to do: don't fork to escape the license, and don't pull this into a non-Ibexa project as an isolated rich-text editor.