- How do I install summerblue/administrator in a Laravel application?
- Install it with Composer via composer require summerblue/administrator, then publish the package config and bundled assets using the provided artisan vendor:publish commands. After publishing, point the package at your existing Eloquent models and add one config file per model to declare columns, edit fields, filters, and actions. Routes are registered under a single admin prefix, so no schema changes or separate services are required. The happy path is fast; the real effort is in auth wiring, relationship tuning, and view overrides.
- Which Laravel and PHP versions does summerblue/administrator support?
- The package is a maintained fork of the long-dormant Frozennode/Administrator, so its compatibility largely follows whatever the forker has patched for recent Laravel majors. There is no strong published support matrix, which means you should verify your target Laravel and PHP versions against the repository's composer.json and CI configuration rather than trusting the release date. Because any Laravel major bump is absorbed by a single maintainer, plan to test upgrades yourself before committing to production use.
- How is summerblue/administrator different from Filament, Nova, or Backpack?
- It is config-driven rather than class-driven: instead of PHP resource classes and Livewire or Inertia components, you write one config file per Eloquent model declaring columns, edit_fields, filters, row and batch actions, validation rules, and a permission closure. Views are server-rendered Blade with a bundled jQuery-era frontend, which is architecturally older than modern admin tooling. That makes it a good fit for a fast internal back office over an existing schema owned by one or two developers, and a poor fit for API-first admin surfaces or workflow-heavy custom UX. It also means the frontend is effectively unupgradable without forking.
- How do I create a CRUD screen for an Eloquent model with summerblue/administrator?
- Create a configuration file for the model that defines the list columns, edit fields, validation rules, filters, and any row or batch actions, then register it so the admin routes pick it up. The package reads that metadata and generates the list, create, edit, and delete screens automatically against your existing Eloquent model. No migrations or data duplication are needed, and effort scales linearly with the number of models you expose. Keep business logic out of the config files and custom actions so a future migration to another admin package stays mechanical.
- Does summerblue/administrator include authentication and permissions?
- Yes, the package ships with authentication wiring, permission closures per model, menus, and dashboard widgets, but you still own the integration details. In practice the cost is not installation but the tail: auth and permission wiring, relationship field tuning, custom actions, localization, and view overrides. There is no evident granular field-level permission or audit logging system, so if you need those you should plan to build them or choose a different tool. You also inherit responsibility for reviewing auth bypass and mass-assignment paths yourself.
- Is summerblue/administrator still maintained and safe to use in production?
- It is a maintained fork of a dormant upstream, effectively with a bus factor of one and roughly 286 GitHub stars, which is a real continuity risk for anything beyond internal tooling. It inherits a large, mature but essentially frozen codebase, so new Laravel major versions depend on the single forker to patch routing, Eloquent, Blade, and service provider changes. There is no evident coordinated disclosure process or CVE feed for the fork, so you must own patch review for auth bypass, mass-assignment, and file-upload paths. For internal back-office use it can be acceptable; for high-value or regulated production surfaces, treat it as a risk you must actively manage.
- How do I customize views, fields, or add custom row and batch actions in summerblue/administrator?
- You can publish the package views and assets, override Blaze templates locally, define custom edit fields, and register custom row or batch actions in each model's config file. Be aware that published views and assets invite local edits, which turn future package upgrades into three-way merges. The bundled JavaScript and CSS are dated, so expect CSP, accessibility, and browser compatibility friction when customizing the frontend. Keep custom logic thin and avoid putting business logic in config files or actions if you may migrate later.
- Does summerblue/administrator support relationships, filters, and validation in forms?
- Yes, the per-model config declares relationship fields, list filters, and validation rules alongside the grid and form definitions. Relationship depth and filtering behavior are areas that need benchmarking rather than assumption, especially for large list views. Because the package assumes direct Eloquent access to the same database, deep relationship chains can be costly. Test against your expected list-view data volumes before committing to a wide rollout.
- Can I use summerblue/administrator in a multi-tenant SaaS or API-first application?
- It is weakest in headless, API-first, multi-tenant SaaS, or microservice topologies where the admin must compose data across services, because the package assumes direct Eloquent access to the same database. It is strongest in a conventional monolithic Laravel app with an existing Eloquent domain layer and Blade frontend deployed as a single artifact. If you need API access, audit logging, or field-level permissions, any yes pushes you toward a different tool such as Filament, Nova, or Backpack. If you adopt it anyway, bound it to a specific internal context such as ops screens for 5 to 15 models.
- What are the alternatives to summerblue/administrator and how hard is migrating off it?
- Modern alternatives include Filament, Laravel Nova, and Backpack, all of which use class-based resources and component-driven frontends. Because summerblue/administrator config files are essentially declarative metadata, they are a reasonable source for a later translation into Filament or Nova resources, but the effort is mechanical rather than automatable, so budget per-model rework. To keep that path open, do not let business logic live in config files or custom actions. Treat it as a bounded internal tool rather than an organization-wide admin standard.