Weave Code
Taxonomies Bundle Laravel Package
sylius/taxonomies-bundle
Sylius Taxonomies Bundle adds taxonomy management to Sylius e-commerce apps, letting you organize products into hierarchical, translatable taxons such as categories and tags via the admin panel.
Flexible categorization system for Symfony2.
Frequently asked questions about Taxonomies Bundle
- Is sylius/taxonomies-bundle a Laravel package?
- No. It is a Symfony2 bundle built on Symfony full-stack conventions of the 2.x era: a Bundle class, XML or YAML dependency injection service definitions, Doctrine ORM entity mappings, and Symfony EventDispatcher hooks. It ships no Illuminate dependencies, no service provider, and no facade, so Laravel's container, Eloquent ORM, and HTTP kernel do not satisfy its runtime contract. Treat it as a reference implementation to read when designing a Laravel taxonomy model, not as an installable library.
- Can I install sylius/taxonomies-bundle in a Laravel application with Composer?
- Direct installation is a non-starter for Laravel. The bundle assumes Symfony's ContainerInterface, HttpKernel, and Doctrine\ORM\EntityManager, none of which Laravel provides out of the box, and it has zero dependents or published adapters that suggest anyone has bridged it. Running it behind a Symfony kernel inside a Laravel app is technically possible but operationally indefensible for a categorization primitive. The realistic path is porting the domain model into Eloquent.
- Why does sylius/taxonomies-bundle conflict with PHP 8.1+ and modern Laravel versions?
- The package's Composer constraints were written for Symfony2, which reached end of life in 2018 and has received no security patches since. Its Doctrine mapping format predates the attribute and annotation migration, so modern Doctrine releases and PHP 8.1+ typing will not line up cleanly. You should also expect abandoned transitive dependencies in the resolution tree. Attempting to force-install it typically produces hard version blocks rather than a working install.
- What does Sylius Taxonomies Bundle actually do?
- It adds taxonomy management to Sylius e-commerce applications, letting you organize products into hierarchical, translatable taxons such as categories and tags. Taxonomies hold presentation metadata like name, slug, and description, while taxons form a tree managed through the admin panel with move, reorder, insert, and delete-and-reparent operations. Most of the bundle's complexity comes from its nested-set tree machinery rather than simple categorization.
- How do I port the Sylius taxonomy data model to a Laravel application?
- Start by cloning the repository and reading the Taxonomy and Taxon entities plus the nested-set logic, then document the columns, indexes, and tree strategy without adding it to composer.json. Recreate the tables as Laravel migrations with explicit foreign keys, an lft/rgt/depth strategy (or parent_id plus path), and a unique constraint on slug scoped by taxonomy. Reimplement tree operations on top of a maintained nested-set package instead of hand-rolling them. Map the presentation metadata such as name, slug, description, and images onto Eloquent casts and accessors.
- What are the best Laravel alternatives for hierarchical categories and tags?
- For genuine multi-level hierarchies, kalnoy/nestedset is the most established maintained option and pairs well with Eloquent, while staudenmeir/laravel-adjacency-list covers parent_id style trees. If your requirement is closer to flat tagging, spatie/laravel-tags is simpler and better supported. If you are actually on modern Symfony rather than Laravel, use Sylius's current taxonomy component instead of this legacy bundle.
- Do I really need nested sets for taxonomies, or is a parent_id column enough?
- It depends on your real functional surface: tree CRUD, slug generation, path enumeration, and ordered output are very different requirements. Much of this bundle's complexity is nested-set machinery you may never exercise, and flat tags with a parent_id column often suffice for simple categorization. Narrowing the requirement determines whether a port takes a day or a sprint. Confirm whether the hierarchy is genuinely multi-level before committing to lft/rgt columns.
- Is sylius/taxonomies-bundle maintained and safe for production?
- The signals are unambiguous: zero stars, zero dependents, a very low package score, and a repository that is a personal fork rather than the canonical Sylius location. Combined with Symfony2 being end of life since 2018, there is no CVE response path for the package or its transitive dependencies. Do not add it to a production Laravel dependency tree. If you reuse code, vendor-read it for the domain model and write your own tests.
- How should I test a ported taxonomy implementation in Laravel?
- Write characterization tests against the original bundle's documented behavior before deleting your reference copy, focusing on tree integrity rather than implementation details. Cover move, reorder, insert, and delete-and-reparent operations, plus uniqueness of slug scoped by taxonomy and path enumeration correctness. Use Pest or PHPUnit with database transactions and assert lft/rgt/depth invariants after every mutation. These tests catch the regressions that nested-set ports most often introduce.
- Is the pjedrzejewski fork the same as the official Sylius taxonomy code, and can I fork it?
- The repository you are evaluating is a personal fork rather than the canonical Sylius monorepo location, so verify it matches the upstream taxonomy code before relying on it. Check the LICENSE file in the repository to confirm the terms and any attribution required for forking the domain model into your own codebase. Forking the data model into an Eloquent implementation you control is far safer than depending on the abandoned Symfony2 bundle. Keep the attribution your license requires in your project's notices.
Weaver
How can I help you explore Laravel packages today?