Classification Bundle Laravel Package

Product Decisions This Supports

• Taxonomy data model for content and media. The bundle provides the shape of a first-class classification system — contexts → categories → media/collections with tags — which is directly reusable as a domain model for content discovery, faceted search, SEO landing pages, related-content modules, and editorial navigation.
• Build vs. buy on taxonomy. Its existence confirms that classification is a commodity concept, while its abandonment confirms it is a maintenance liability. The right decision it supports is "thin in-house model with tests and migrations," not "adopt a bundle."
• Roadmap input for search, faceting, and segmentation. "Contexts" map cleanly to product segmentation (e.g., per-tenant, per-locale, per-channel catalogs). If the roadmap includes faceted search or personalization, this is a cheap reference for how to scope categories vs. tags vs. collections.
• Editorial tooling scoping. The Sonata Admin coupling is a proxy for what an internal CMS/back-office needs: CRUD for taxonomy, tree management, publishing state, and slug/translation handling. Useful when estimating internal admin work.
• Legacy portfolio triage. If the team inherits a Symfony 2 / Sonata application, this helps decide whether to keep, fork, or sunset the classification layer before a platform migration.
• Opportunity signal, not adoption signal. The high opportunity score reflects a gap for a maintained, modern taxonomy package (particularly for Laravel) — it is a "build this ourselves or find an active equivalent" prompt.

When to Consider This Package

Consider only if all of the following hold:

• You are maintaining a legacy Symfony 2.x application already running Sonata Admin / SonataClassificationBundle, and this extension supplies specific entities or admin wiring you cannot replicate cheaply.
• Your Composer constraints are pinned to EOL PHP (5.x/7.0-era) and Symfony 2.8, and you have no near-term upgrade path.
• You can vendor or fork the code and accept zero upstream support: no security patches, no PHP 8 compatibility, no issue triage.
• Your exposure is bounded — a single internal app with a defined sunset date, not a customer-facing platform.

Look elsewhere if:

• The project is greenfield, or the stack is Laravel — this is a Symfony bundle with no Laravel integration, service providers, or Eloquent support.
• You require PHP 8+, maintained dependencies, active CI, or a security disclosure process.
• You need multi-tenant taxonomy at scale, versioned taxonomies, or complex permissioning on categories.
• Signals disqualify it on their own: 0 stars, 0 dependents, archived repository, single-maintainer history, no release activity. There is no ecosystem to lean on for fixes or answers.
• Alternatives: stay on SonataClassificationBundle if already in Symfony; otherwise implement native taxonomy entities (polymorphic taggables/categorizables, adjacency-list or nested-set trees). In Laravel, evaluate spatie/laravel-tags plus kalnoy/nestedset, or a small custom domain module.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is not a dependency we should adopt. It is an archived Symfony 2 bundle with zero stars, zero dependents, and no maintenance path — putting it in a product creates an unowned liability with no security response. Its value is conceptual: it validates that content classification (categories, tags, collections, channel contexts) belongs in the product as a first-class domain concern, and it gives us a proven shape for that model. Recommendation: no adoption; extract the model, build a small owned module, and revisit only if an actively maintained package emerges.

For engineering (summary): Treat rz/classification-bundle as a design reference, not a dependency. Read it for the entity relationships and admin ergonomics; do not import Symfony 2 / Sonata coupling into a Laravel or modern Symfony codebase. Expected effort for an equivalent in-house module is roughly 2–4 weeks for schema, migrations, tree handling, admin CRUD, and tests — owned by us, on a supported PHP version, with a migration path. If a legacy Symfony 2 app already depends on it, contain it: pin versions, vendor the code, document it as frozen, and schedule replacement before the next platform upgrade.