- What is vanilo/admin and do I need Vanilo to use it?
- vanilo/admin is the presentation layer of the Vanilo e-commerce framework for Laravel, providing routes, controllers, Blade views and CRUD definitions for managing products, orders, customers, pricing and promotions. It is not a standalone admin panel and assumes vanilo/framework already owns the domain model. If Vanilo is not your commerce core, the package offers no value. Evaluate it only after deciding that Vanilo is the system of record for catalog and order data.
- How do I install vanilo/admin in a Laravel application?
- Installation is a standard Composer require into a Laravel app that already runs Vanilo, followed by publishing the package config and assets. The mechanical steps are trivial; the real effort is aligning authentication guards, the permission model, routing conventions and the asset pipeline with your existing application. Run the install in a scratch Laravel plus Vanilo project first so you can verify every screen against the exact pinned release rather than against documentation defaults.
- Which Laravel and PHP versions does vanilo/admin support?
- The package is pinned to a specific Vanilo major, which in turn constrains the supported PHP and Laravel versions, and the admin UI also depends on a Backpack major. Treat PHP, Laravel, Vanilo and Backpack as a single versioned ensemble and lock them together in composer.lock. Check the composer.json of the exact release you intend to use for the authoritative support window, because documentation defaults may not match the pinned tuple.
- Does vanilo/admin require Backpack for Laravel?
- Historically the Vanilo admin UI has been built on Backpack for Laravel, so Backpack is part of the runtime stack and the customization story. Confirm this against the release you plan to pin, because it materially changes both how you extend screens and how you handle upgrades. A Backpack major bump is a coordinated multi-package upgrade event, not an independent Composer update.
- How do I customize the admin UI without forking vendor files?
- Extend through Concord module registration for routes, menus and permissions rather than patching files inside the vendor directory. Overriding Blade views and routes is the common approach in practice, but it behaves like a soft fork and can break silently on upgrade. Keep a regression checklist for every overridden view and prefer configuration-level changes wherever the package allows them.
- Can I use vanilo/admin with a headless or API-first frontend?
- You can, but the admin is a server-rendered Blade application with its own auth and deploy path, so it adds a second parallel UI surface next to your API or SPA. That is a real operational cost rather than a footnote, since it means another authentication boundary and another release pipeline to maintain. It fits Laravel monoliths with Blade admin screens far better than decoupled architectures.
- How do I add a custom admin screen or menu item to Vanilo admin?
- Register new screens as Concord modules and hook your routes, menu entries and permissions through the module registration points instead of grafting code onto vendor controllers. This keeps your additions upgradeable and separate from the package internals. Before building, check how much of your required screen set ships out of the box, since out-of-the-box coverage reduces the customization surface you have to maintain.
- What license does vanilo/admin use, and are there commercial dependencies?
- The package itself is MIT licensed at the top level. However, the Backpack dependency family may include commercially licensed add-ons, so confirm licensing before procurement sign-off. Verify the dependency tree of the exact pinned release rather than relying on the top-level license alone.
- How do I upgrade vanilo/admin safely when Vanilo or Backpack releases a new major?
- Plan upgrades as a coordinated event across PHP, Laravel, Vanilo and Backpack, pinned together in composer.lock as one artifact. Validate published assets and configs against the exact release and run a regression pass over any views or routes you have overridden, since those behave like a soft fork. Assign clear ownership for the upgrade, because there is effectively a single maintainer upstream and no support network to lean on.
- Is vanilo/admin production-ready, and what are the alternatives?
- It is usable in production within a Vanilo-based Laravel monolith, but the adoption signal is low: roughly 7 stars, zero dependents and thin issue traffic, which makes you an early adopter rather than a fast follower. There is no migration tooling from other admin products, so adopting it is greenfield inside Vanilo; if you already run a Laravel admin, mount Vanilo admin behind a feature gate and migrate domain area by domain area. For non-Vanilo stacks, a general-purpose Laravel admin package is a better fit, because the domain logic here lives entirely in vanilo/framework.