Tag Admin Bundle Laravel Package

Getting Started

The first thing to internalize is that mw/tag-admin-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no publishable config, no Blade views — none of the integration points a Laravel developer reaches for. composer require mw/tag-admin-bundle will pull code that expects Kernel::registerBundles(), the Symfony DI container, and almost certainly Doctrine + an admin layer (Sonata or similar). There is no shim, bridge, or adapter that makes this run in a Laravel app. It is a category mismatch.

So "getting started" means one thing for a Laravel developer: read the source as a design reference, do not install it. If you are evaluating it for a legacy Symfony app, use a throwaway app to inspect it — never a real one.

Look in this order:

1. composer.json — read the require block first. It is the real verdict. It tells you which Symfony minor (likely 2.x/3.x, pre-Flex), and which sibling bundles (FOSUserBundle, SonataAdminBundle, older Doctrine, Assetic) you'd be freezing yourself to. If it names abandoned siblings, stop.
2. DependencyInjection/ — the config tree and required services; shows what the bundle genuinely needs versus what it assumes.
3. Resources/config/ — service wiring, routes, admin definitions.
4. Entity/ or Model/ — the Tag model and its assignment mapping. This is the only artifact you're actually likely to want.

The realistic "first use case" is a one-session port: extract the tag entity field set and the tag↔entity join mapping from the bundle, and reimplement them as a Laravel Tag model with a morphToMany/belongsToMany pivot and an admin controller. That yields the bundle's value (the schema and CRUD interaction pattern) with none of the dependency risk. Budget hours, not days — the domain surface is genuinely tiny.

Implementation Patterns

Because actual adoption is off the table (archived, 1 star, 0 dependents, wrong framework), the day-to-day patterns are about extraction, not usage:

Pattern 1 — Spec extraction (the Laravel default). Treat the repo as documentation. Pull out and port:

• The Tag field set — typically name, slug, timestamps, sometimes createdBy.
• The join/pivot shape between Tag and the tagged entity (polymorphic pivot vs. a per-entity join table).
• Repository helpers — "find or create by name," slug-based lookup, "reassign-then-delete." These are the behaviors worth copying, because the CRUD screens are trivial and the lifecycle rules are not.

Reimplement in Laravel as an Eloquent Tag model, a taggable trait (morphToMany), a slug column with a unique index, and an Admin\TagController behind your admin middleware group (or a Filament/Nova resource). One migration, one model, one trait, one controller, one form request. That is the whole product.

Pattern 2 — Fork-and-vendor (only if you are genuinely on legacy Symfony). MIT permits it, and archived means nobody upstream will ever conflict with you. Fork into your own namespace, drop it under src/, rewrite services.yml to autowired/autoconfigured service definitions, replace FOSUserBundle coupling with your own user provider, and replace Sonata coupling with EasyAdmin or a hand-rolled controller. You keep the entity and lifecycle logic; you throw away the framework glue. You now own it entirely.

Pattern 3 — Isolated legacy dependency (only if it already runs in production). If a legacy Symfony app already depends on it, keep it fenced: pin the exact version, add a smoke test that boots the kernel and hits the admin route, and treat any PHP/Symfony upgrade as a manual patch task against your fork. Do not spread it to new services.

For a Laravel developer the honest day-to-day answer: there is no day-to-day. You read it once, port the schema and lifecycle rules, and never touch it again. That is the correct outcome, not a shortfall.

Gotchas and Tips

• Do not attempt a bridge. There is no ServiceProvider analogue, no bundle loader in Laravel, and no meaningful incremental coexistence path. "Adapting" it is a greenfield rebuild wearing a dependency's clothes.
• Check composer.json before anything else. The php and symfony/* constraints date the code and tell you whether it runs on any supported runtime. If you see Symfony 2.x/3.x, assume it won't run on modern PHP without patching.
• Look for removed APIs. getRequest() on controllers, the Controller base class, SensioFrameworkExtraBundle @Route annotations, assetic: asset references — any of these means it's unrunnable even in legacy Symfony without rewrites.
• Expect abandoned sibling coupling. Bundles of this vintage typically lean on FOSUserBundle, SonataAdminBundle, SensioGeneratorBundle, or Assetic — all themselves effectively retired. Breakage cascades, and you inherit every layer.
• Assume the admin surface is unaudited. This is an admin UI from an era with weaker defaults; do not assume CSRF/XSS/mass-assignment review ever happened. If you fork, audit the forms and output escaping yourself.
• Archived status inverts the maintenance curve. Every PHP minor, framework advisory, and dependency bump becomes an internal obligation with no upstream to defer to. Risk acceptance is signed by your team because there's no vendor to escalate to.
• MIT is the one clean property. It permits forking — but a fork means full ownership: security, compatibility, and knowledge retention (the understanding of your deviations leaves with whoever wrote them).
• Debugging tip: when a legacy Symfony bundle of this age fails, it's almost never the bundle's own logic — it's the container failing to compile due to a missing or renamed sibling service. Read DependencyInjection/ and Resources/config/ together, not separately.
• Extension point that actually matters: the entity and its lifecycle rules, not the controllers. Copy the former; rewrite the latter in your framework's idiom.
• Don't mistake a cheap ramp-up for low total cost. A competent engineer reads this in an afternoon, but the output is context, not capability — you still build it yourself. For new Laravel work, use a maintained tagging package or a Filament/Nova admin resource; the build is genuinely small.