Administrator Laravel Package

Getting Started

1. Install the package (check your Laravel version first — this is a legacy fork of Frozennode/Laravel-Administrator, so expect to pin it against older Laravel releases):

   composer require exodusanto/administrator
   

2. Register the service provider in config/app.php (this package predates auto-discovery reliably working for older Laravel branches):

   'providers' => [
       'Exodusanto\Administrator\AdministratorServiceProvider',
   ],
   'aliases' => [
       'Admin' => 'Exodusanto\Administrator\Facades\Administrator',
   ],
   

3. Publish config and assets, then run the install command:

   php artisan vendor:publish
   php artisan admin:install
   

   This drops config/administrator.php and scaffolds config/administrator/ — that directory is the heart of the package. Look here first; the entire admin UI is derived from these config files, not from migrations or model schemas.
4. Create your first config file at config/administrator/users.php:

   return [
       'title'       => 'Users',
       'single'      => 'user',
       'model'       => 'App\User',
       'columns'     => ['id', 'name', 'email'],
       'edit_fields' => [
           'name'  => ['type' => 'text'],
           'email' => ['type' => 'text'],
       ],
   ];
   

5. Visit /admin — you should see a sidebar entry for Users with full CRUD, filtering, and pagination generated automatically. Your first real use case is almost always the users table plus one or two domain tables (posts/orders/products), because that instantly buys you a backoffice without writing controllers or views.

Implementation Patterns

• One config file per model. Each file in config/administrator/ maps to a route and a menu entry. Keep filenames lowercase and matching the URL you want (config/administrator/blog_posts.php → /admin/blog_posts).
• Columns drive the index table. columns supports 'relation.name' dot notation and a 'select' expression for computed columns:

  'columns' => [
      'id',
      'profile.company' => ['title' => 'Company'],
      'total' => ['select' => 'SUM(orders.amount)'],
  ],
  

• edit_fields is your form builder. Use type (text, textarea, wysiwyg, image, file, enum, key, markdown), plus relationship for FK pickers:

  'edit_fields' => [
      'author' => ['type' => 'relationship', 'name_field' => 'name'],
      'status' => ['type' => 'enum', 'options' => ['draft', 'published']],
  ],
  

• Define filters per column. These become the search/filter bar above the table — extremely cheap compared to building custom filter UIs:

  'filters' => [
      'created_at' => ['type' => 'date', 'title' => 'Created'],
      'status'     => ['type' => 'enum', 'options' => [...]],
  ],
  

• Actions for bulk operations. actions let you run code across selected rows from the index view — a clean place for "Publish", "Export CSV", "Archive":

  'actions' => [
      'publish' => [
          'title' => 'Publish Selected',
          'messages' => ['active' => 'Publishing...'],
          'action' => function ($query) { $query->update(['status' => 'published']); },
      ],
  ],
  

• Gate access via the permission closure in config/administrator.php. This is the standard integration point with Laravel auth / roles:

  'permission' => function () {
      return Auth::check() && Auth::user()->is_admin;
  },
  

• Use the Admin facade for menu customization and route wiring — e.g. Admin::menu([...]) in a service provider to reorder or group items, and Admin::model('User')->... for programmatic access.
• Override views by publishing them (php artisan view:publish) rather than editing vendor files — this is the primary extension point for branding, layout, and per-field rendering tweaks.
• Integrate with custom fields by extending the field class and registering it, so you can keep exotic form inputs (rich pickers, map inputs) inside the same config-driven model.

Gotchas and Tips

• This is a legacy package with low activity (39 stars, 0 dependents). Pin the version explicitly in composer.json and be prepared to maintain or fork it. Do not assume it works with the newest Laravel — check the composer.json of the repo for the illuminate/* constraints before adopting.
• Config caching kills dynamic behavior. php artisan config:cache in production will bake in config/administrator/*.php files, and any closures (permission, action, visible) will fail to serialize. Run config:clear when debugging "my file doesn't appear in the menu."
• File naming is the route. A mismatch between filename, single key, and $model class is the #1 source of silent empty pages. The single value must be singular and unique across all config files.
• Permission closure is called on every request. Do not put expensive DB queries inside it; cache role lookups. Also verify it returns a boolean and not a truthy user object — some auth drivers leak through.
• Validation belongs in rules per field, not in FormRequests. The package's own validation layer is what the UI trusts; a custom FormRequest won't run. Use rules and messages keys inside edit_fields.
• Relationship fields need the right key shape. For belongsTo use 'type' => 'relationship' with name_field; for many-to-many add 'multiple' => true and ensure the pivot table exists — the package does not create migrations for you.
• Debug via the facade and the resolved config. dd(Admin::model('user')->getColumns()) from php artisan tinker is the fastest way to see why a column or field isn't rendering.
• Route collisions with your own /admin routes. The package registers its route group early; if you have a custom admin area, either move the package's prefix (config('administrator.prefix')) or load your routes later with a distinct prefix.
• Assets are old — the bundled DataTables/jQuery versions will fight modern frontend stacks. Isolate the admin under its own layout (which it already does) and never try to merge its JS with your SPA build.
• Extension points worth knowing: custom field classes, custom column types, the Admin::menu() hook, published views, and the actions closures. Almost everything else is hardcoded in the vendor tree — fork if you need deeper changes.
• Treat it as a scaffold, not a framework. It's excellent for getting a functional internal CRUD panel fast; it is not a good fit for anything that needs modern auth (Sanctum/passport flows), API-first backends, or long-term upgrade paths.