Classification Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for taxonomy features. This package (a fork of Sonata's ClassificationBundle) is a working reference implementation of the classification domain model most products eventually need: contexts (scopes/tenants), categories (nested, tree-structured), collections, and tags. Use it to size the "categorization/taxonomy" epic before committing engineering time.
• Feature scoping for admin & CMS surfaces. It shows the CRUD, tree management, slugging, and block-rendering requirements that come with "let editors organize content" — useful input for roadmap estimation and for deciding whether taxonomy is a v1 or v2 feature.
• Data model decisions. Multi-context categorization (same content model reused across tenants, locales, or channels) is a recurring product ask. The bundle's entity relationships are a concrete artifact to review when deciding how to model categories vs. tags vs. freeform collections.
• Prior art for a "catalog / navigation / content organization" roadmap item — including how taxonomy hooks into rendering (Sonata Block integration), which drives downstream decisions on caching, SEO, and merchandising.
• Not a dependency decision. With zero stars, zero dependents, archived status, and no released maintenance story, treat it as documentation and design evidence, not as a build candidate.

When to Consider This Package

Consider it when:

• You are on Symfony 2.x/3.x with Sonata Admin and need a taxonomy layer to study or fork for an inherited legacy app.
• You need a reference schema for contexts/categories/collections/tags and want to compare against your own design.
• You are writing a spec or spike for a content-organization feature and want a known-good example of nested-set categories, sluggable entities, and admin-driven tree management.
• Your product has multi-tenant or multi-channel content and you need to pressure-test whether context-scoped taxonomy is worth the complexity.

Look elsewhere when:

• You are starting greenfield or on Symfony 5+/6+/7 — use the maintained sonata-project/ClassificationBundle or a modern alternative (Sylius taxonomy, Doctrine Tree extensions, or a custom service), not this archived fork.
• You need API/headless-first taxonomy — this bundle is coupled to server-rendered admin + block rendering.
• You need active security patching, support SLAs, or a vendor relationship. Archived + 0 dependents = no community signal, no upgrade path, no one to call.
• Your taxonomy needs are simple (flat tags) — the nested-set + context model is heavier than necessary.

How to Pitch It (Stakeholders)

Executives: This is an archived, unmaintained open-source component with no adoption. We are not proposing to ship it. We are using it as a free design artifact to de-risk a taxonomy/content-organization feature: it answers "what does this feature actually require?" before we spend sprint time. Outcome: better estimates and a clearer build-vs-configure recommendation, at effectively zero cost.

Engineering: Treat rmzamora/classification-bundle as read-only prior art on top of Sonata ClassificationBundle. It demonstrates the canonical Context → Category (nested set) / Collection / Tag model with Gedmo behaviors and Sonata Admin CRUD/block wiring. Do not add it as a dependency: archived, zero stars, zero dependents, no upgrade path. If we reuse anything, we lift the entity and relationship design into our own code or adopt the maintained sonata-project/ClassificationBundle if we're already on that stack. Please review it as input to the taxonomy ADR before we commit to a schema.

Recommendation: Reference only. No adoption, no procurement, no support commitment.