- Can I install fpn/tag-bundle in a Laravel application?
- No, not as a normal Composer dependency. It is a Symfony bundle that depends on the Symfony bundle lifecycle, dependency injection extensions, service YAML, and Doctrine ORM mappings, none of which Laravel provides out of the box. Its Symfony 2.x-era constraints will likely conflict with modern Laravel's symfony/* 6 or 7 pins, so Composer resolution will usually fail. Treat it as a design reference rather than a package to install.
- What does FPN TagBundle actually do?
- It adds reusable tagging to Symfony applications backed by Doctrine. Any entity can implement the Taggable interface to gain tags, while manager services handle tagging, untagging, and querying tagged resources. It also supports tag clouds with usage counts and weights through a configurable tag entity.
- Does fpn/tag-bundle support Laravel 10 or Laravel 11?
- There is no official Laravel support. The bundle was built for Symfony 2.x-era constraints and PHP 5.3+, while Laravel 10 and 11 pin modern Symfony 6 or 7 components. Forcing installation with --ignore-platform-reqs produces an untested runtime that Laravel cannot wire up without a rewrite.
- Is fpn/tag-bundle maintained and safe for production?
- The project shows strong dormancy signals: about 75 stars, zero dependents, and no active maintainer. There is no security patching, no PHP 8.x guarantee, and no regression test net for fixes you might make. It belongs in a vendor-risk register and is not recommended for production Laravel applications.
- What are the best Laravel alternatives to FPN TagBundle?
- For a standard Laravel and Eloquent stack, use spatie/laravel-tags or a hand-rolled morphToMany relationship. Both are Eloquent-native, maintained, and cover polymorphic joins plus tag queries. They deliver the same categorization and filtered-listing use cases without Doctrine or Symfony baggage.
- How hard is it to port FPN TagBundle to Laravel Eloquent?
- A port is a bespoke rewrite, typically one to two sprints including data migration. You would lift the Tag and Tagging schema plus TagManager semantics into Eloquent models, a trait, and a small service. Symfony dependency injection would become a service provider, and Symfony event subscribers would become Laravel model events.
- What are the main technical risks of using fpn/tag-bundle with Laravel?
- The loud risks are dependency resolution conflicts and abandonment, because the bundle targets old Symfony and PHP versions with no active maintainer. Doctrine ORM 3 drift can break annotation-based mappings outright. Polymorphic join tables also usually lack foreign keys to the tagged resource, so orphaned taggings accumulate and require application-level cleanup you own forever.
- Does fpn/tag-bundle work with Doctrine ORM 3?
- It is unlikely to work without changes. Doctrine ORM 3 removed substantial legacy API surface, and annotation-based mapping from this bundle's era breaks outright. You would need to confirm the declared doctrine/* constraints and whether the code even parses under PHP 8.2 or newer.
- How does FPN TagBundle implement tagging and tag clouds?
- It uses a Tag entity, a Tagging polymorphic join entity with taggable_type and taggable_id, a Taggable interface plus trait, and manager services such as TagManager. A TaggableListener event subscriber connects Doctrine entities to the tagging workflow. Tag clouds are built from tag usage counts and weights.
- Should I use FPN TagBundle or build my own tagging in Laravel?
- For a standard Laravel and Eloquent codebase, build or adopt a native solution because the bundle is conceptually relevant but mechanically incompatible. It is acceptable only as a design reference for a Doctrine-backed Laravel service or a legacy Symfony app. Most teams should use a maintained Eloquent package or a small morphToMany implementation instead.