Dumps
dump() and dd() from any PHP site, Artisan command or queue worker show up on the Dumps screen, as well as where they normally print. Each one shows the site, and the file and line it came from. There’s nothing to install in your project: DevKit loads a small PHP file before your code runs.
The Capturing switch pauses and resumes capture, and DevKit remembers it. While it’s paused, new dumps are discarded.
Laravel details
Section titled “Laravel details”With Laravel details on, Laravel sites also report:
| Tab | What you see |
|---|---|
| Queries | Each SQL query with its bindings and time. Queries over 100 ms are marked. |
| Jobs | Jobs as they’re queued, and when a worker finishes or fails them, with how long they took. Failures are marked. |
| Views | Each Blade view rendered, with the names of the data passed to it. Laravel’s own error page views are left out. |
| HTTP | Requests your app makes with Laravel’s HTTP client, with status and time |
| Logs | Log messages. Errors are marked. |
DevKit adds this by registering its own service provider when Laravel boots. Your composer.json and config/app.php aren’t changed. Turn Laravel details off if a project doesn’t get along with it. Each kind keeps its latest 500 entries, so a burst of queries never pushes your dumps out.
The provider also lets Laravel’s HTTP client reach your other .test sites (see Troubleshooting). With Laravel details off, DevKit doesn’t touch Laravel apps at all, so that’s off too.
Filtering
Section titled “Filtering”Pick a site in Sites to see only its dumps; the tabs filter by kind. Clear empties the list.
On the Queries tab, Slower than shows only queries that took at least 10, 50 or 100 ms, the search box matches the SQL, the request or the file, and Slowest first sorts by time. A busy queue worker polls the database constantly; a 10 ms threshold hides that noise.