Formatter Bundle Laravel Package

Product Decisions This Supports

• Buy vs. build on the formatting layer — with a caveat. The bundle is a reference implementation of a formatter abstraction: a content field stores a formatter key alongside its value, and the rendering layer dispatches to the right renderer (raw HTML, Markdown, WYSIWYG/rich text). That separation — store the choice, resolve at render time — is the durable design idea. The package itself is not the buy candidate; the pattern is.
• Legacy Symfony/Sonata estate triage. If your portfolio includes Sonata Admin back-offices, this tells you what a content-editing dependency chain looks like: SonataAdmin + a formatter bundle + a CKEditor integration + an HTML sanitizer. Useful for scoping the cost of a migration off a pinned, unmaintained admin stack.
• Roadmap input: content authoring, not new builds. Nothing here justifies roadmap allocation for a new product. It informs the "what does it cost to keep the CMS admin alive vs. replace it" question, and the answer is typically "replace the field-level editing experience, keep the content model."
• Sanitization policy decision. A formatter layer is where rich-text risk concentrates. This bundle's dependency on an HTML purifier is a reminder that any rich-text feature you ship needs an explicit allow-list policy owned by product, not inherited from a library default.
• Anti-signal for vendor evaluation. 0 stars, 0 dependents, archived, and a personal-namespace fork of an upstream project. This is the canonical shape of a dependency that should never enter a procurement shortlist. Use it to calibrate your dependency-admission checklist rather than to make a feature decision.

When to Consider This Package

Consider it only as a reading reference, not as a dependency:

• You are maintaining an existing Sonata Admin application and need to understand how formatter selection was wired in a previous generation of the stack — as archaeology, to plan removal.
• You are designing a formatter abstraction from scratch and want a concrete, small example of the "formatter key stored per field" pattern before writing your own.
• You need to reproduce a legacy behavior precisely during a migration and the upstream documentation has drifted.

Look elsewhere — decisively — when:

• You are on Laravel. This is a Symfony bundle built for the Sonata Admin ecosystem. It has no Laravel service provider, no config publishing, no Blade integration. The framing of this evaluation as a "Laravel/PHP package" is itself a mismatch worth flagging to whoever requested it: there is no integration surface here for a Laravel application. For Laravel rich text, evaluate a maintained editor package plus a dedicated sanitizer (e.g., an HTML purifier binding) rather than a formatter bundle.
• You need anything maintained. It is archived. No security response, no PHP-version compatibility work, no framework-version tracking. Any adoption means you own the fork, the patching, and the CVE triage — permanently, for a 0-star artifact.
• You need ecosystem validation. Zero dependents means zero field-tested edge cases and no community to consult. The failure modes are unknown and undiscovered.
• You are starting greenfield. Use a maintained editor (Tiptap, Lexical, or a framework-native editor) with server-side sanitization; do not adopt an admin-bundle-shaped solution for a product surface.

How to Pitch It (Stakeholders)

Executives: This is an archived, unmaintained fork of a Symfony admin component with no users and no downstream dependents. It does not represent a build-vs-buy option — it represents a migration liability if it appears anywhere in our dependency tree, and nothing at all if it does not. Recommendation: no investment, no adoption. The only value is as a design reference for a content-formatting abstraction we would write ourselves in a few days. Action requested: none beyond confirming it is absent from our inventory.

Engineering: Treat this as a spec, not a dependency. The one idea worth extracting is the formatter-key-plus-value content model — store which formatter produced a field, resolve it at render time, and keep sanitization as an explicit, policy-driven step rather than a library default. If we are on Laravel, note that this package is architecturally irrelevant to us (Symfony/Sonata only); do not attempt to bridge it. If we are maintaining a Sonata Admin back-office that already pulls this in, this is a signal to schedule an exit: pin it, audit it for CVEs, and put the formatter layer on the replacement roadmap rather than the upgrade roadmap — because there is no upgrade path.