Admin Bundle Laravel Package

Getting Started

• Still not a Laravel package. v0.6.0 adds persistence abstraction and a front-end refactor, but there is no service provider, no config publishing, no Eloquent/Blade bridge. If your stack is Laravel, treat this as a reference implementation to borrow structure from, not a dependency.
• The release is real work, not a version bump. Doctrine ORM and PDO adapters, a jQuery-free ES2015 JavaScript rewrite, and Twig component extraction. That makes the source materially more interesting to read — and materially more likely to break your overrides if you already vendored it.
• Verify constraints again before anything else. The changelog says nothing about PHP or symfony/* bounds, and "IE11 compatible", "ES2015", and "PDO support" all point at a Symfony 3.4/4.x-era codebase. Read composer.json first; if the constraint solve fails on your Symfony version, nothing below matters.
• Where to look first, in order: README.md, composer.json (constraints + the lin3s-front-foundation pin), the JS entry file and asset build config (new in this release), Resources/views/components/ (the new home of shared Twig components), DependencyInjection/Configuration.php, Resources/config/services.*, the persistence abstraction layer (ORM adapter vs PDO adapter), then Controller/ and Menu/.
• First use case: stand up one admin screen, same as before — register, import routing, add a menu entry pointing at your own controller, override the layout. But before you style anything, read the extracted button, filter, flash_message, and form_collection components: they moved and were refactored, so any override recipe you find online (or in your own older fork) points at the wrong path.
• Still near-zero stars/dependents and no docs beyond the README + changelog. The changelog is now the only place upgrade hazards are recorded, and it records exactly one: a BC break.

Implementation Patterns

• Extend rather than configure. Unchanged: subclass the base admin controller/menu layer, keep domain logic in your own services, let the bundle own routing, menu assembly, and layout chrome.
• Menu as the integration seam. Build the menu in application code (builder service or tagged collector), let the bundle render it. Keeps sections addable without touching vendor code.
• Copy the persistence seam — this is the most transferable idea in the release. One abstraction, two adapters (Doctrine ORM, PDO), is exactly the shape you want if you ever need swappable storage behind a Laravel service. It is a pattern to imitate, not code to install: there is no Eloquent adapter and no Laravel bridge.
• Own your front-end build. jQuery is gone and the bundle's JS is now ES2015 classes written against a module entry file, transpiled for IE11. Any integration should compile the bundle's sources through your own Encore/Mix/Vite pipeline rather than trusting prebuilt assets. Note the implication: the package now assumes a JS build step exists at all, which is a new prerequisite versus earlier 0.x tags.
• Twig components → Blade components. The extraction of panel/button/filter components into a components/ directory maps almost one-to-one onto anonymous Blade components and <x-...> slots. If your goal is to learn from this repo, port the component boundaries, not the Twig.
• Overriding: Symfony 3 uses bundle inheritance (getParent()), Symfony 4+ uses templates/bundles/<BundleName>/.... Override into the new components/ path, not the old partial/ one.
• If you must ship it, vendor it. Fork, tag your own version, require via a VCS repositories entry. This release is a good argument for forking: you get a place to absorb the component BC break once and patch it forward without upstream.
• Day-to-day leverage remains conceptual. A small readable admin scaffold with menu rendering and now a clean persistence abstraction. Copying the structure into app/Admin/ still costs less than integrating it.

Gotchas and Tips

• The BC break is the headline: Twig components moved and were refactored. button, filter, flash_message, and form_collection went from partial/ to components/. Grep every template for the old include paths before upgrading. Silent failure mode: Twig happily renders nothing (or throws on a missing template) and you lose a button or a filter bar with no stack trace pointing at the bundle.
• jQuery was removed. If your layout overrides or admin scripts assumed $ was globally available from the bundle's layout, they now throw $ is not defined. Same for any plugin you attached to the bundle's old markup.
• The javascripts Twig block moved from the top to the bottom of <body>. Anything you appended to that block now executes after content render — good for DOM queries, fatal if any inline handler or global defined in that block was consumed earlier during render. If you override the layout, check block position explicitly.
• ES2015 + IE11 compatibility are only true together if you rebuild correctly. The shipped code is transpiled; the source is not. Rebuilding with a modern Babel/Encore target silently drops IE11 (and older Safari) support. This pairing also dates the package — it's a 2018-era front-end toolchain.
• lin3s-front-foundation coupling is now visible and churny. The changelog bumps it twice in this release window (0.5.0 → 0.6.0 → 0.6.1). Pin both packages to matching versions; a mismatch shows up as broken layout/CSS with no PHP error.
• Doctrine ORM and PDO only. The persistence abstraction does not imply the controller/menu layer is storage-agnostic — check whether admin controllers still assume entities. And do not read "PDO support" as "Laravel-friendly": there is no query builder, no Eloquent, no migrations.
• Translatable string-list field content means the translation domain/catalog must line up with the bundle's expectations, or you get raw keys in the UI. Check the configuration file for the domain it assumes.
• No security layer, still. The bundle gives chrome, not authorization. Wire firewalls/access_control yourself and filter menu items by role at build time — the menu will render links to routes the current user cannot reach.
• Service definitions remain XML/YAML with explicit IDs. No autowiring, no attribute routing. Everything you inject into an extended admin class must be declared in your own service config.
• Debugging: debug:container --tag=<bundle tag> and debug:router to see what was registered, then read the class. Add grep -r 'partial/' templates/ and a look at the compiled asset output to this routine — the new failure modes are template-path and asset-pipeline shaped, not service-shaped.
• Version pinning is non-negotiable and got more specific. Pin the exact tag and the matching lin3s-front-foundation version, then audit with composer why-not.
• Migration guidance: greenfield → skip it; use EasyAdmin/Sonata on Symfony, Filament/Nova on Laravel. Legacy on an earlier 0.x → upgrade deliberately, components first: audit overrides, drop jQuery assumptions, re-verify block placement, rebuild assets. Keep all bundle coupling behind your own admin controllers so a replacement touches one directory.