Console Bundle Laravel Package

Getting Started

Add the bundle for development only:

composer require --dev winzou/console-bundle

Register it in app/AppKernel.php, gated to the dev environment so it can never be loaded in production:

if (in_array($this->getEnvironment(), ['dev', 'test'], true)) {
    $bundles[] = new Winzou\Bundle\ConsoleBundle\WinzouConsoleBundle();
}

Import its routing (usually under a dev-only prefix, or behind a firewall):

# app/config/routing_dev.yml
winzou_console:
    resource: "@WinzouConsoleBundle/Resources/config/routing.xml"
    prefix:   /console

Then open /console in the browser and type a command such as cache:clear or doctrine:schema:validate.

Look first at: the Winzou\Bundle\ConsoleBundle\Controller\ConsoleController (the indexAction renders the terminal UI; the command action resolves the Application and executes the command) and the routing XML — that shows you exactly which commands are reachable and under which HTTP method.

First use case: running cache:clear, assets:install, and doctrine:schema:update on a shared host or a sandbox where you have no SSH. It's a convenience wrapper around Symfony's Application, so any command your kernel can discover (core + your bundles) is available without typing a full shell invocation.

Implementation Patterns

Command discovery is automatic. The bundle boots a Symfony Console\Application against your kernel, so every command registered in your bundles appears. To add a bespoke "run in the browser" command, create a normal command class in your bundle; nothing extra is needed for it to show up in the console.

Lock it behind the firewall. The safest pattern is to register the bundle only in dev and restrict the route. Combine the dev-only bundle registration with a firewall rule (or an access_control entry) requiring ROLE_ADMIN or a local IP check:

access_control:
    - { path: ^/console, roles: ROLE_ADMIN, ip: 127.0.0.1 }

Wrap common tasks as custom commands instead of typing raw ones. If your team uses the console daily for repetitive operations (fixtures, imports, cache warmup), define thin custom Commands that encapsulate the arguments, then invoke them from the browser. This keeps the browser surface small — one command per workflow, with no user-supplied options.

Debug commands for the dev loop. Good candidates: cache:clear, cache:warmup, doctrine:cache:clear-metadata, assets:install, router:debug, debug:container. Anything interactive (e.g. doctrine:fixtures:load --no-interaction needed) or destructive should get an equivalent non-interactive custom command.

Non-interactive only. The controller executes commands via the standard Application, but there is no TTY, so anything that prompts (doctrine:fixtures:load asking to confirm, generate:controller asking questions) will fail or hang. Prefer commands that accept --no-interaction, -n, or all options as flags. Build your custom commands to read configuration rather than prompt.

Output shape. The console streams plain text back to the browser via AJAX; ANSI escape codes will show up as literal garbage. If your custom commands emit progress or formatted tables, keep them simple, or strip colour codes (OutputInterface::OUTPUT_PLAIN / --no-ansi) before they reach the browser.

Environment control. To run a command against another environment (e.g. clearing the prod cache from a dev box), the console lets you pass --env=prod, but remember the PHP process still runs with the dev kernel's services. Where possible, run commands with explicit flags so the behaviour is reproducible from the command line as well.

Gotchas and Tips

• Never enable this in production. It is a remote command execution endpoint with no built-in authentication or allow-listing. Anyone with the URL who can reach the app can run any command the kernel exposes. Gate on dev environment and auth — belt and braces.
• Symfony 2 only. The bundle targets the Symfony2 kernel/console APIs and is unmaintained. Do not attempt to install it on Symfony 3+/4+; the Application construction differs and the bundle will not boot. Treat it as a legacy tool for existing Symfony 2 apps.
• Interactive commands hang. Any command that calls $input->isInteractive() and waits for input will block until the PHP/web-server timeout. Use --no-interaction and pre-built flags.
• Timeouts bite before commands fail cleanly. cache:clear and doctrine:schema:update on a large app can exceed PHP's max_execution_time or nginx/FPM timeouts; the browser request dies with a 504 while the command may have partially completed. Run potentially long commands through a queue instead, or at least keep the console for short operations.
• Output buffering and memory. The controller collects output in memory before sending it back; very chatty commands (debug:container, large fixture loads) can exhaust memory limits. Prefer targeted commands over debug:* on large containers.
• Permissions are the PHP user's, not yours. Cache/log write failures you don't see over SSH (because your shell runs as a different user) will surface here. Check app/cache / app/logs ownership for the FPM/CLI user before blaming the console.
• Cache rebuild after bundle changes. If the console stops discovering a command, clear the cache — the kernel/command map is cached, and a stale dev cache is the usual culprit.
• Composer + --dev. Install it as a dev dependency and exclude it from production deploys (composer install --no-dev). If the bundle is conditionally registered in the kernel, the app still boots in prod without the class present.
• Extension points. The controller and the Twig template are the two places to customise: override the template from your app to add buttons/shortcuts for the commands your team runs most, and extend the controller (or add your own route/controller that decorates it) if you need to whitelist which commands are executable rather than exposing the full set.