- Can I use helios-ag/fm-bbcode-bundle in a Laravel application?
- No. This is a Symfony bundle (Composer type symfony-bundle) whose entire integration surface, including kernel registration, a DependencyInjection extension, a Configuration tree and Twig bundle wiring, assumes a Symfony full-stack kernel. Laravel never calls Kernel::registerBundles(), uses its own service providers and config repository, and ships Blade instead of Twig. There is no hook point for the bundle to attach to, so the package cannot be dropped into a Laravel app even in principle.
- Why does composer require helios-ag/fm-bbcode-bundle fail in a Laravel project?
- Dependency conflict is the hard blocker. The 7.0 release explicitly targets Symfony 3 compatibility, so it pins Symfony and Twig packages to that era, while a modern Laravel app pins the symfony/* components to current majors. Composer will either fail dependency resolution outright or drag symfony/framework-bundle in as a transitive dependency, and neither outcome is acceptable in a Laravel codebase. No version of the package currently avoids this conflict.
- What does helios-ag/fm-bbcode-bundle actually do?
- It is a thin configuration and wiring layer over the lightweight FM BBCode parser. It registers a parser service, exposes a config tree for tag whitelists, smiley/emoticon maps, URL and video handlers and HTML passthrough rules, and provides Twig filters and extensions for converting BBCode markup into HTML. The real value is the curated parser configuration rather than the bundle code itself, which is roughly 200 to 400 lines of config plus a thin call site.
- Which Symfony and PHP versions does the 7.0 release support?
- The 7.0 release is a deprecation-cleanup pass that targets Symfony 3, which reached end of life in January 2019. That places the supported PHP range in the 5.5 to 7.x era, and the release notes give no signal of PHP 8 support. There is also no meaningful UPGRADE guide beyond a single line, so even the Symfony-side diff is opaque.
- Is helios-ag/fm-bbcode-bundle still maintained?
- It is best described as near-dormant rather than abandoned. There are sporadic single-maintainer releases, the most recent of which is limited to Symfony 3 deprecation hygiene rather than a framework or PHP modernization, and it has zero Packagist dependents and no visible issue triage. A maintenance release that re-baselines on an eight-year-old EOL framework line confirms the maintainer's target is Symfony 3, not a modern stack. Budget for a bus factor of one.
- Is BBCode parsing with this bundle safe against XSS?
- Security is the highest risk here. User-generated BBCode combined with any HTML-passthrough capability is a textbook XSS surface, and an effectively unmaintained parser means any sanitization bypass stays permanently unfixed, with no upstream patch and no CVE feed watching it. The 7.0 release is a deprecation cleanup, not a security release, so it should not be read as evidence of an active security response process. Depending on a Symfony 3 stack also inherits that EOL framework's unpatched surface on top of the parser's.
- How do I render BBCode to HTML in Laravel instead?
- Use a maintained parser such as s9e/TextFormatter, which has a mature BBCode plugin and is actively maintained. Install it with Composer, register the BBCode plugin in a small service class, and bind it through a Laravel service provider or a Blade directive. Port the tag, smiley and URL handler configuration from this bundle's config tree so your rendered markup keeps the same semantics as your existing content.
- Can I fork the bundle and replace the Symfony classes with a Laravel service provider?
- That fork-and-strip approach is feasible in principle: keep the curated configuration, throw away the bundle classes, and re-expose the underlying parser through a Laravel service provider and facade. The unknown you must spike first is whether the underlying parser runs on PHP 8.x, since the 7.0 release gives no signal and targets a Symfony 3, PHP 5.5 to 7.x era codebase. Expect breakage from removed create_function, dynamic-property deprecations, old-style regex modifiers and untyped interface signatures.
- Does the bundle work with Blade templates?
- No. The package ships Twig filters and extensions, and Twig is not the default templating engine in Laravel. To get equivalent behavior you would re-implement the rendering as a Blade directive, a helper function or a view component that calls your parser service. That is a small amount of code, but it confirms the bundle itself provides nothing reusable on the Laravel side.
- What are the best alternatives to this bundle for a Laravel project?
- The most feasible path is re-implementing on a maintained parser, with s9e/TextFormatter being the standard choice thanks to its BBCode plugin and active release cadence. Add a small config-parity layer so tag whitelists, smileys and URL handling behave the same as your old configuration, and wrap it in a Laravel service provider with a Blade directive for rendering. That gives you the only part of this package that was actually valuable, the curated configuration, without inheriting an EOL Symfony 3 dependency.