Laravel Debug Console Laravel Package

Getting Started

This package is a query-inspection layer: it captures the SQL your application runs and renders it in a browsable table (typically a debug route or panel). 1.0.3 is a patch release in that rendering layer, not an API change, so the day-to-day workflow is unchanged — it just stops long, unbroken strings from destroying the table layout.

1. Install and let package discovery register the service provider:

   composer require <vendor>/<package>
   

2. Publish the config (and views only if you intend to customise them):

   php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider"
   

3. Enable it for local only — never leave it on in production:

   APP_DEBUG=true
   QUERY_MONITOR_ENABLED=true
   

4. Clear compiled views after the upgrade, since the fix lives in a Blade template:

   php artisan view:clear && php artisan config:clear
   

First use case: load the slowest page in your app, open the queries table, and sort by duration. The immediate win over DB::listen() + dump() is that bindings, timing, and the calling file are already correlated in one view.

Where to look first: the published config file (enable flag, retention/limit, ignored tables), then the package's route/middleware registration if you need to restrict access.

Implementation Patterns

Environment gating. Treat the whole package as a local/staging tool. Gate the route behind auth in non-local environments rather than relying on the enable flag alone:

// config/<package>.php
'enabled' => env('QUERY_MONITOR_ENABLED', app()->environment('local')),

Pair with Telescope rather than replacing it. Telescope is better for request/job/event correlation; this package is better for reading a wide, copy-pasteable query table. Run both locally; disable one to avoid double overhead on heavy pages.

Use it as a regression tool. Before/after a refactor, hit the same endpoint and compare query counts. Keep a short checklist in your PR description: query count, N+1 offenders, slowest query.

Capture CLI and queue context too if the package exposes a console/queue hook — otherwise your table only reflects HTTP requests and you'll misdiagnose queue-heavy paths.

Custom views are a fork. If you publish and edit the queries table view, you own the fix. See gotchas below.

Gotchas and Tips

The 1.0.3 fix is a display-only fix — and you may not get it. The bug was that wordwrap() does not split words longer than the width by default, so a 2,000-character JSON payload, base64 blob, minified JS, or a giant WHERE id IN (...) list rendered as one unbreakable cell and pushed the table off-screen. The fix almost certainly lives in the Blade template. If you have published views, composer update will not touch your copy — diff the package's view against yours and port the change, or republish and re-apply your customisations. php artisan view:clear is required either way if compiled views are cached.

Long strings still exist in your data. The fix changes wrapping, not truncation. If you copy SQL out of the table for reproduction, verify you're getting the full statement and not a visually wrapped fragment. Consider explicitly truncating large bindings at capture time if the package supports a max_length/except option.

Don't leak bindings. Query tables show raw parameter values — passwords in INSERTs, tokens in WHERE clauses, PII in payloads. Keep the tool local-only, and check whether the package offers binding redaction before you ever run it against a staging DB seeded from production.

Overhead scales with query volume. A page issuing 800 queries in a loop will show you 800 rows, and the capture/wrap cost is real. Disable via the enable flag when profiling large seeders or imports.

wordwrap and multibyte text. PHP's wordwrap is byte/locale-sensitive; CJK and emoji-heavy strings may still wrap oddly. If your app stores user-generated content with long unbroken runs (URLs, hashes, stack traces), spot-check the table after upgrading.

Upgrade risk is low. 1.0.3 is a patch release with no signature or config changes reported; bump it and move on. Pin with ^1.0 and re-read the changelog when a minor bumps, since view-layer fixes are exactly the kind of thing that gets silently lost through published assets.

Debugging a broken table: if the layout still blows out after upgrading, the cause is usually your own pre/code CSS or a published view — inspect the rendered cell in devtools and check white-space and overflow-wrap before assuming the package is at fault.