Adminer Laravel Bridge Laravel Package

Product Decisions This Supports

• Whether to keep an in-app database console at all. This bridge serves Adminer (a single-file PHP DB admin tool) through Laravel routing and asset serving, so engineers and support can inspect data on staging/ops environments without installing a desktop client or standing up a second service like phpMyAdmin. The build-vs-buy calculation is cheap on both sides: the wrapper is thin, so the real dependency and the real risk is upstream Adminer, not this package.
• Dependency cadence, not roadmap. 6.2.0 is a pure upstream pin bump — no bridge API change, no config change, no new Laravel-side capability, no migration work. It should ride the routine dependency-update train and should not anchor any feature planning.
• Driver-specific value decisions. The release matters only if the upstream fixes map to our stack: PostgreSQL (concurrent index create/drop, extension-typed columns outside search_path, \connect import, collation in Create database, server-level export), SQLite (named/preserved checks, declared column types on alter, table/column comments, check alteration without table rebuild on 3.53+), MySQL/MariaDB (ON UPDATE CURRENT_TIMESTAMP precision), Firebird (PDO_Firebird; the unmaintained InterBase extension is dropped).
• Customization scope. New upstream plugin hooks — Plugin::$optional, Plugin::disable(), doc and default_sql driver field keys, and Driver::errorLine() — are the supported way to tailor the UI, link internal docs from column names, or switch plugins off by default. Use these instead of forking.
• Risk acceptance. The bridge's automated coverage is wiring, routing and asset serving; it explicitly does not exercise Adminer's UI behind a live DB connection. Manual smoke testing on our drivers is a required part of the decision, not an optional QA step.

When to Consider This Package

Adopt when:

• You need a lightweight, self-hosted DB console reachable from the Laravel app, gated by existing auth middleware and environment checks rather than exposed as a separate service.
• Your stack benefits from the 6.2.0 fixes above — particularly PostgreSQL and SQLite, which absorb the bulk of the upstream changes.
• You want supported hooks (Plugin::$optional, Plugin::disable(), doc, default_sql) to customize the UI or disable plugins by default.
• Your team is comfortable owning a periodic version-pin bump of a vendored admin tool and enforcing env-gating.

Look elsewhere when:

• You need audited, multi-user, role-based data administration — that's Nova/Filament resources, a managed DB console, or a dedicated admin product, not a shared-credential DB client.
• Production exposure is even on the table. Adminer is a full DB console; the bridge adds no authorization. The correct default is "do not deploy to prod."
• You require vendor-backed guarantees. This release was cut automatically once the test matrix and asset smoke test passed; it makes no claim about UI correctness against a live database.
• You depend on the legacy InterBase extension (dropped) or on UI behavior outside the bridge's smoke-test surface.
• A desktop client or artisan db/tinker already covers the need — a browser DB console is a standing attack surface for marginal value.

How to Pitch It (Stakeholders)

Executives: We can give engineers and support a database browser inside the app, behind our existing login, at essentially zero infrastructure cost. This release is maintenance-only — the wrapper code did not change; it moves the bundled Adminer to 6.2.0, which is upstream bug-fix work (mostly PostgreSQL and SQLite schema editing). No app changes, no migrations, nothing user-visible in our product. Recommend taking it on the normal dependency cadence.

Engineering: The bridge diff is a one-line pin bump to vrana/adminer 6.2.0, auto-cut after the full test matrix and asset smoke test passed — but those cover routing, wiring and asset serving only, not Adminer's UI against a live database. Treat the upstream changelog as the source of truth and do a manual smoke pass on the drivers we actually use (Postgres and SQLite see the most change; MySQL/MariaDB only a timestamp-precision fix; Firebird support now requires PDO_Firebird). No config or code changes are needed to upgrade. If we customize the UI, use the new supported hooks — Plugin::$optional, Plugin::disable(), the doc and default_sql driver field keys, and Driver::errorLine() — rather than patching. Keep the route environment-gated and behind auth middleware.