Fm Bbcode Bundle Laravel Package

Product Decisions This Supports

• Legacy content migration and forum parity. If you are migrating a vBulletin/phpBB-style community, or importing user-generated content authored in BBCode, this package is a reference for the shape of that work — tag whitelisting, [b]/[url]/[quote] rendering, and converting stored markup into safe HTML. It informs scoping of a "legacy formatting compatibility" epic rather than being a production dependency.
• Build vs. buy for a narrow formatting utility. BBCode is a small, well-bounded problem (unlike a forum engine or editor suite). The 7.0 release is a useful data point in the other direction: a version bump that only clears Symfony 3 deprecations is maintenance of a compatibility floor, not of a product. That nudges the decision toward a thin in-house parser or a maintained library rather than vendoring this one.
• Feature/roadmap triage. BBCode support is almost always a retention feature for existing communities, not an acquisition feature for new products. This package helps you decide whether BBCode belongs in the current roadmap (only if migrating an existing corpus) or should be deprecated in favor of Markdown/rich-text for all new authoring.
• Risk and dependency governance. An effectively dormant, license-ambiguous, zero-dependent Symfony bundle is a concrete example for your dependency policy: how you treat abandoned libraries, and whether Symfony-specific bundles have any place in a Laravel codebase (they do not, directly).
• Framework-fit validation. This is a Symfony bundle, not a Laravel package. The most valuable PM decision it supports is confirming that framework-native abstractions (Symfony Bundle, DI service definitions) do not port to Laravel service providers — so any evaluation of "can we reuse this?" resolves to "no, we'd adopt the underlying BBCode library, not the bundle." The 7.0 release reinforces this by tightening its target to Symfony 3 specifically, a framework generation we are not on.

When to Consider This Package

Consider it only if:

• You are on a Symfony 3 application in a PHP 5.5–7.x era codebase where this bundle's service wiring matches your framework version, and 7.0's deprecation cleanup is the reason you are unblocking an upgrade.
• You need BBCode rendering with a configurable tag whitelist and are comfortable vendoring or forking an effectively dormant dependency.
• The scope is genuinely small and internal — e.g., displaying archived forum posts in a read-only view — with no exposure to untrusted input flows you cannot sandbox.

Look elsewhere when:

• You are building on Laravel. This bundle will not install or boot without Symfony's bundle infrastructure; the correct move is to evaluate the underlying BBCode parser directly or a maintained alternative. 7.0 makes this more explicit — it targets Symfony 3, full stop.
• You need a supported framework generation. Symfony 3 reached end of life in November 2021. A release that optimizes for Symfony 3 is optimizing for a framework line that itself receives no security fixes; it is not evidence of a living project.
• You require maintained dependencies or modern runtimes. There is no indication of PHP 8 support, no security-release cadence, and no XSS/CVE response. BBCode parsers are a classic injection surface — treating stored markup as HTML is a security decision, not just a formatting one.
• License clarity matters. Nothing in a Symfony-compatibility bump addresses the existing NOASSERTION status; you still cannot confirm redistribution rights without legal review before shipping in a commercial product.
• You need modern authoring. For new content, prefer Markdown or a constrained rich-text editor; reserve BBCode handling for one-way import/render of legacy data.

How to Pitch It (Stakeholders)

To executives: This is a small Symfony library for rendering BBCode (the old forum markup format). A new 7.0 release landed, but it is narrow: it makes the bundle run on Symfony 3 without deprecation warnings — a compatibility cleanup, not new capability. It remains not recommended as a dependency for our Laravel-based product: it targets a different framework, in fact a framework version that is itself end-of-life, and nothing in this release resolves the unconfirmed license or the absence of a security-response cadence. Its value to us is purely informational — it clarifies the cost of supporting legacy forum content during migration and reinforces that we should handle BBCode with a thin, in-house renderer or a maintained library rather than adopting dormant code.

To engineering: Do not add helios-ag/fm-bbcode-bundle to the Laravel codebase — it is a Symfony bundle and will not integrate, and 7.0 explicitly pins its ambition to Symfony 3. If we need BBCode support, treat the requirement as "render and sanitize legacy markup," scope it as a small, testable module (whitelist tags, escape by default, never trust stored markup), and choose a maintained parser or write ours against the same interface. Treat the 7.0 changelog as a signal of scope, not revival: a deprecation-clean Symfony 3 build carries no PHP 8 story and no security commitment. Keep the NOASSERTION license as a hard blocker for any exception request; if a specific legacy-parity need arises, capture it as a backlog item with an explicit security review, not a framework package adoption.