Weave Code
Admin Bundle Laravel Package
sylius/admin-bundle
Sylius AdminBundle delivers the default administration panel for Sylius stores, offering a clean Symfony and Twig interface to manage products, orders, customers, promotions, taxes, and settings. It provides reusable grids, forms, and resource CRUD screens that speed up building custom e-commerce ba...
Sylius eCommerce administration panel component.
Frequently asked questions about Admin Bundle
- Can I install sylius/admin-bundle in a Laravel application with Composer?
- No. sylius/admin-bundle is a Symfony bundle, not a Laravel package, so Laravel has no mechanism to load its DI container configuration, routing, security firewalls, Twig templates, or Webpack Encore assets. Composer may resolve the download, but nothing will register the admin UI or mount it at a route. Treat it as a separate Symfony/Sylius application rather than a dependency of your Laravel app.
- Is sylius/admin-bundle deprecated, and what should I use instead?
- Yes, the split repository is explicitly deprecated; admin functionality now ships inside the sylius/sylius monorepo. Even for a Symfony team, the correct consumption path is the distribution via composer create-project sylius/sylius or composer require sylius/sylius, which pins the matching admin bundle version. Composer-requiring this split repo directly means stale code with no independent release train, issue tracker, or PR target.
- Does sylius/admin-bundle support Laravel versions, Blade, or Eloquent?
- None of these apply. The bundle assumes Symfony routing and the Symfony service container, Twig for templating, Doctrine ORM entities from the Sylius domain model, and Sylius security conventions such as sylius_admin_user_provider, the admin regex firewall, and ROLE_ADMINISTRATION_ACCESS. There is no Blade view layer, no Eloquent models, and no Laravel guard integration. Bridging it would mean re-implementing the bundle rather than configuring it.
- Which PHP and Symfony versions does the Sylius admin panel require?
- Versions are pinned by the Sylius release you install rather than chosen freely, so the split repo has no meaningful constraint set of its own. In practice you inherit the Symfony LTS line and PHP version supported by the Sylius major you adopt, plus matching Doctrine, Twig, and asset-build tooling. That Symfony-to-Sylius-to-PHP coupling is one of the main upgrade risks, so pin all three deliberately and for a defined support window.
- What packages does sylius/admin-bundle depend on?
- It builds on Sylius ResourceBundle for the CRUD and resource abstraction, GridBundle for the configurable listing and filtering definitions, and UiBundle for macros and layout. It also requires the Sylius domain entities (Product, Order, Customer, Promotion, Channel) via Doctrine ORM. Because the admin screens are thin configuration on top of those layers, none of them have equivalents in a standard Laravel stack.
- What is a good Laravel alternative to Sylius admin for an e-commerce backend?
- For a Laravel-native admin, Filament, Nova, Backpack, or a custom Livewire panel can cover catalog, order, customer, and promotion screens with far less integration cost. A common architecture is headless Sylius behind an API for commerce logic, with a Laravel admin consuming it. Keep in mind you would be rebuilding roughly the 70 to 80 percent of commerce ops screens that a mature admin already defines.
- How can a Laravel team use Sylius admin without merging the two codebases?
- Run Sylius as a separate service and let the Laravel app own its own domain, with a clear sync contract of events, queues, or a synchronous API between them. Decide explicitly who is system of record for customers, prices, and stock, and integrate identity through SSO or OIDC rather than duplicating auth and session models. This keeps both stacks upgradeable and avoids the Symfony-versus-Laravel runtime conflict entirely.
- How do I override Twig templates, grids, and the admin menu in Sylius admin?
- Template overrides use standard Symfony bundle inheritance, grid and resource listings are configured in YAML, and services and menu builders are extended through decoration in your application code. Do these overrides in your Sylius application, not by forking this split repository, or you will lose the changes at the next upgrade. Note that Twig block names changed materially between Sylius 1.x and 2.x, so overrides are not portable across majors.
- Why does the GitHub repo show so few stars and dependents?
- That is an artifact of the subtree split, not a health signal. Development, issues, security posture, and release cadence all live in the Sylius/Sylius monorepo, so adoption and maintenance metrics must be measured against the parent project. Internal scorecards should exclude this repo's standalone opportunity score or explicitly re-baseline it against Sylius.
- What are the main upgrade and production risks with the Sylius admin bundle?
- Expect Symfony, Sylius, and PHP version coupling, duplicated identity and auth models when paired with a Laravel app, and ambiguous database ownership for customers and stock. Asset builds add a second toolchain, typically Node with Webpack Encore alongside Vite, and the admin UI changed significantly in Sylius 2.0. The deprecated split also creates organizational confusion, so factor in Symfony capacity and a defined upgrade cadence before committing.
Weaver
How can I help you explore Laravel packages today?