Helpers Laravel Package

Getting Started

The helpers extension is a developer toolbox that plugs extra tools into an existing laravel-admin panel (Encore's laravel-admin). It assumes you already have a working admin installation with a route prefix (default /admin) and at least one admin user.

Install it like any laravel-admin extension:

composer require laravel-admin-ext/helpers

Then register the extension so its menu item and tool routes are wired up:

php artisan admin:import helpers

That command creates the Helpers menu entry in the admin sidebar (under a Helpers parent node) and registers the extension's routes and views. After that, log into /admin and open the Helpers menu — you should see the tool list (scaffold generator, route list, log viewer, system/php info, and documentation shortcuts, depending on version).

Look first at:

1. config/admin.php → extensions array — confirm helpers is enabled once imported; if the menu doesn't show, this is almost always the culprit.
2. vendor/laravel-admin-ext/helpers/src/ — the service provider and the Helpers controller tell you exactly which tools are shipped and how routes are named. Read this before assuming a feature exists.
3. The Helpers menu node in the admin UI — the first real use case is usually the route list: it gives you a sortable, filterable view of every registered route (method, URI, name, action, middleware) rendered inside the admin chrome, which is far quicker than php artisan route:list when you're clicking between resources.

A good first use case: open Helpers → Routes, filter for a resource you just scaffolded, and confirm the generated resource routes and middleware are what you expect before writing any UI.

Implementation Patterns

Scaffold-driven CRUD bootstrapping. The scaffold tool is the highest-leverage piece. It lets you pick a table, choose field types, and generate an admin controller + grid + form in one pass. The typical workflow:

1. Create the migration and model normally (php artisan make:model -m).
2. Open Helpers → Scaffold, choose the table.
3. Configure the grid columns (which fields show in the list) and form fields (types, validation hints).
4. Generate — this writes a controller into app/Admin/Controllers/.
5. Wire it into app/Admin/routes.php ($router->resource('posts', PostController::class);).
6. Review the generated controller — the scaffold is a starting point, not a final product.

This is much faster than hand-writing $grid->column(...) and $form->text(...) for every field, and it's the reason people install this package.

Debugging in the browser instead of the terminal. The log viewer reads storage/logs/laravel.log (and rotated files) and renders entries in a filterable list. The day-to-day pattern is: trigger the failing action, then open Helpers → Logs, filter by level or by a request ID/exception type, and copy the trace — all without SSH when you're on a remote dev box or a colleague's machine.

Route and system introspection. The route list tool is the browser equivalent of artisan route:list, useful for spotting duplicate URIs, unexpected middleware, or a route that got shadowed by an earlier registration. The system info panel (PHP version, extensions enabled, disk usage) is handy when onboarding someone onto an environment whose stack you don't know.

Documentation shortcuts. The package links out to Laravel and laravel-admin docs from the admin UI. This is low-value if you already have bookmarks; skip it if you don't care.

Guarding tools behind roles. In any non-local environment, wrap or middleware-protect the helpers routes. The standard pattern is to gate them in app/Admin/routes.php or via the admin permissions table — assign the Helpers menu node to a developer role only. Never expose the scaffold or terminal-like tools to end users.

Extending the toolbox. If you want to add your own tool, the package's service provider is the extension point: it registers tool routes and views from src/. Copy that pattern — add a route and view in your own admin extension, then add a menu item — rather than forking the package.

Gotchas and Tips

It's stale — treat it as legacy. Last release was October 2021 and it has essentially no downstream dependents. It targets the Encore-era laravel-admin (1.x line). On modern Laravel (10/11/12) or a forked admin panel, expect breakage: class names, Blade syntax, and route middleware groups may have drifted. Always composer require in a branch and smoke-test every tool before merging.

The "terminal"/artisan feature is a footgun. If your version ships a command runner, it's effectively remote code execution behind an admin login. Lock it down hard: role-gated menu, IP allowlist middleware, and disabled entirely on production. If you can't guarantee that, remove the route.

Scaffold output is unvalidated. Generated controllers often include permissive validation, all fields in both grid and form, and no authorization checks. Review every generated file for: $form->...->rules(...), canSee/canEdit gates, and whether sensitive columns (tokens, password hashes) leaked into the grid. Delete fields you don't want exposed — the scaffold doesn't know your domain.

Menu doesn't appear after admin:import. Check, in order: (1) config/admin.php extensions.helpers is present and true; (2) you re-ran the import after upgrading the package; (3) the admin_menu table actually got the Helpers row — re-import with php artisan admin:import helpers --force if not; (4) your admin user's role has permission for that menu node.

Log viewer permission and rotation. The viewer needs read access to storage/logs. On Docker/sail setups the web user may differ from your shell user, so chmod -R ug+rw storage/logs is common. Also be aware it only shows what's on disk — if log rotation or a LOG_CHANNEL=daily setting trimmed the file, older entries won't be there.

Route caching defeats the tool's value. If you've run php artisan route:cache, the routes tool still reads the registered routes at request time, but any discrepancy between cached and actual routes is a classic "why doesn't my new route work" bug. Clear the cache (php artisan route:clear) when routes look wrong; don't blame the viewer.

Non-default admin path breaks tool links. The extension often hardcodes or assumes the admin prefix when building URLs in its views. If you've customized the prefix via config/admin.php route.prefix, verify the helpers links point to the right place; if they don't, override the view or fix the URL generation in a local fork.

Config publishing. Publish the extension config with php artisan vendor:publish --tag=laravel-admin-helpers (tag name varies by version — check the provider's publishes() call) so you can toggle tools rather than editing vendor files.

Maintenance strategy. Given the lack of releases, pin the version in composer.json, commit the lockfile, and audit it whenever you bump Laravel or the admin package. For production, consider using it only in local/staging, or extracting just the pieces you need (a routes view, a log view) into a small internal extension you control.

Alternatives worth knowing. barryvdh/laravel-debugbar (dev), opcodesio/log-viewer (logs), and a plain terminal cover most of what this package does — often with active maintenance. Use helpers if you specifically want the tools inside the admin UI; otherwise reach for the dedicated packages.