- How do I install php-console/laravel-service-provider in a Laravel app?
- Install it with Composer via composer require php-console/laravel-service-provider, then register the service provider manually in the providers array of config/app.php. After that, publish the package configuration with php artisan vendor:publish so you can set the PHP Console connection details and the environments where debugging is enabled. You also need the PHP Console Chrome extension installed and configured with a matching password before any output appears in the browser.
- Does php-console/laravel-service-provider support Laravel 10, 11 or 12?
- No. The package is a Laravel 4/5-era bridge with no release since 2015, and it predates the provider registration changes introduced in Laravel 11. It also depends on the underlying php-console library, which assumes a PHP 5.4 through 7.x runtime. Running it on any currently supported Laravel version requires a fork and is not a realistic upgrade path.
- Is Laravel package auto-discovery supported by this package?
- No. Auto-discovery arrived in Laravel 5.5 in 2017, well after this package stopped receiving releases, so its composer.json has no extra.laravel block. You must add the provider to config/app.php yourself in older apps, or to bootstrap/providers.php in Laravel 11 and later if you are attempting a fork. This manual registration step is one of the reasons the package is easy to forget about in a codebase.
- How do I stop PHP Console from sending debugging data in production?
- The package ships a publishable configuration file with environment gating, so you can restrict the handler to local or staging environments and keep it out of production entirely. The safer approach is to only require the package in require-dev and never deploy it to production at all, since the remote console can execute arbitrary PHP. Treat any environment reachable from outside a developer machine as off limits.
- How does the Laravel logging handler forward messages to PHP Console?
- The service provider hooks into Laravel's logging and exception handling during boot and registers a handler that routes log records and errors to the PHP Console client. Once registered, messages written through the Log facade, plus uncaught exceptions and PHP errors, appear in the browser extension instead of only in log files. It also exposes a helper and facade so you can push variables, stack traces and notices on demand.
- Is php-console/laravel-service-provider safe to run in production?
- No, and it should not be deployed there. Its core feature is a remote console that executes PHP sent from a browser extension, so a leaked console password, a shared staging host or VPN-less access turns a debug convenience into full application compromise. There is no security advisory channel and no maintainer to ship a fix. Keep it confined to a local development container or remove it.
- What are good alternatives to PHP Console for Laravel debugging?
- For variable dumping, Ray offers the best developer experience, while symfony/var-dumper with spatie/laravel-ray or the built-in dd and dump helpers covers most needs for free. For request, query and exception inspection, Laravel Telescope and spatie/laravel-ignition are actively maintained and integrate cleanly with current Laravel versions. Xdebug with a proper IDE remains the most reliable option for step debugging.
- Why does Composer warn that this package is abandoned?
- The last tagged release was in June 2015 and the repository has had no maintainer activity since, so Packagist flags it as abandoned. It also has zero dependent packages, meaning no community fork or downstream project is carrying fixes forward. Composer will still install it in a legacy app, but you get no patch path for PHP 8 incompatibilities or Laravel major version bumps.
- Does this package conflict with Ignition, Whoops or Laravel Telescope?
- It can. The provider registers global error and exception handlers, which collide with spatie/laravel-ignition, Whoops and Telescope's own handlers, and handler ordering determines which one actually runs. The resulting bugs are subtle and often show up as swallowed exceptions or missing stack traces. If you must keep the package in a legacy app, register it last and verify that exceptions still surface correctly.
- Does the PHP Console Chrome extension still work in modern Chrome?
- The PHP Console extension is a Manifest V2 Chrome extension, and Chrome has retired MV2 support in current releases, so it may no longer load on a managed browser fleet. That makes the extension the hard dependency rather than the PHP side, because you cannot vendor, pin or audit a browser add-on. If the extension stops working, the package becomes inert no matter how much you patch the PHP code.