Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Laravel Service Provider Laravel Package

php-console/laravel-service-provider

Integrates php-console with Laravel by registering the console as a service provider, so you can build and run custom CLI commands using Laravel's container, config, and Artisan-style workflow.

View on GitHub
Deep Wiki
Context7

Getting Started

1. Install (dev only)

composer require --dev php-console/laravel-service-provider

Install the PHP Console Chrome extension (barbushin) and open its options to set a password.

2. Register the service provider

  • Laravel 4: add 'PhpConsole\Laravel\ServiceProvider' to the providers array in app/config/app.php.
  • Laravel 5: same class name in config/app.php under 'providers'.

Wrap it in an environment check so it never registers outside local development:

if (App::environment('local')) {
    $app->register('PhpConsole\Laravel\ServiceProvider');
}

3. Publish and edit the config

# Laravel 4
php artisan config:publish php-console/laravel-service-provider
# Laravel 5
php artisan vendor:publish --provider="PhpConsole\Laravel\ServiceProvider"

In the resulting config, enable the handler and set the same password you typed into the extension. Check the sourcesBasePath-style key (if present) points at your project root so the extension can open file/line links in your editor.

4. Where to look first

  • The published config file — it decides whether anything works at all.
  • vendor/php-console/laravel-service-provider/src/... — it's a very thin provider; reading it takes two minutes and tells you exactly what is bound.
  • The upstream php-console/php-console README for the PC:: API surface, since this package only wires it up.

5. First use case

Load any page of your app in Chrome, click the PHP Console toolbar icon — it should show a connected/green state. Then in a controller:

PC::debug(['user_id' => $id, 'payload' => $request->all()], 'checkout');

Reload. The dump appears in the extension's console tab, tagged checkout, with no output in the page body and no var_dump left to clean up.

Implementation Patterns

Replace var_dump / dd during request debugging. PC::debug($value, 'tag') sends structured data through response headers, so it survives return response()->json(...) and views without polluting output. Use tags consistently ('query', 'payload', 'auth') so the extension groups them.

Remote PHP execution against live request state. The extension's "Run PHP" box executes code inside the currently loaded page's PHP context — effectively Tinker, but bound to a real request with its container, session and authenticated user. This is the package's strongest day-to-day feature for "why is this variable wrong in production-like conditions" work. Use it read-only (Cache::get(...), DB::table(...)->count(), Auth::id()); avoid mutating state you can't reason about.

Error surfacing without app.debug noise. The provider registers PHP error/exception handlers, so notices, warnings and stack traces land in the extension's Errors tab instead of being swallowed or turning into a white screen. Useful in Laravel 4/5 projects where the default handler renders a generic page.

Wrap it in your own facade/helper. The package is unmaintained, so keep your call sites decoupled:

// app/Support/debug.php
function pc_debug($value, $tag = null)
{
    if (class_exists('\PhpConsole\Helper')) {
        \PC::debug($value, $tag);
    }
}

Now ripping the package out in a year is one function body, not a codebase-wide search.

Gate by environment at the registration site, not just the config flag. Config flags get copied between environments; an App::environment('local') guard in AppServiceProvider::register() (or bootstrap/start.php for L4) is the real safety net.

Pair with Log for anything you need after the fact. PHP Console data exists only in the browser tab that produced it. If you may need the value later, also Log::debug(...).

Gotchas and Tips

Production exposure is remote code execution. Remote PHP execution + a password is an RCE surface if the password leaks or is brute-forced (there's no rate limiting in the library). Never enable it on a public host; env-gate the provider and deny the route/extension header at the edge if you can.

It's a 2015 package. Last release 2015-06-30, targeted at Laravel 4.x/5.0. On Laravel 6+ the provider's contract signatures and config publishing conventions will likely need edits; on PHP 8 you may hit deprecations or fatal errors inside the upstream library. Budget for a fork rather than a composer update.

The Chrome extension is the other half of the dependency. It's Manifest v2-era and effectively unmaintained; recent Chrome versions disable such extensions. Verify it still loads before you invest in a workflow around it. Firefox is not supported.

It's HTTP-only. Data is delivered via response headers, so it does not work in artisan commands, queued jobs, scheduled tasks, or long-running workers. In CLI you get nothing, silently.

Headers must still be writable. Anything that flushes output early (echo, var_dump, large file downloads, streamed responses, some middleware) means the payload never reaches the browser. Output buffering is your friend — enable it if the extension stays "disconnected."

Redirects lose the payload. Debugging a POST that redirects: your dump is attached to the 302 and the browser moves on. Debug on the destination page instead.

Large dumps break the response. Payloads ride in headers; big arrays can exceed Apache's LimitRequestFieldSize or nginx's large_client_header_buffers, producing a 400/502 with no obvious cause. Slice arrays (array_slice($x, 0, 20)) or dump keys first.

Password mismatch looks like "no connection." If the extension shows an auth error or stays grey while the app clearly boots the provider, re-check the password in both the published config and the extension options — that's the single most common setup failure.

AJAX is hit or miss. JSON/XHR responses often don't surface in the extension's tab state unless you keep that tab focused during the request. Load the endpoint in a normal browser tab when you need to inspect it.

Extension points are minimal by design. The provider only registers PhpConsole\Helper. If you need different behaviour (custom error levels, filtering, per-route toggling), skip the package and register the upstream helper yourself in a three-line service provider — you'll be on a maintained-by-you path with the same result.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect
youbar/easy-crud
c-point-labs/laravel-hostyourai
dbravoan/dbcms-admin-theme-dbcms
dbravoan/dbcms-theme-db-cyber
dbravoan/dbcms-blocks-basic
dbravoan/dbcms-module-content-audit
dbravoan/dbcms-module-ai-assistant
paygate-to/paygate-php
padosoft/askmydocs-connector-base
defstudio/supercharged-carbon
bernskioldmedia/laravel-matomo