README

Run Symfony console commands and PHP scripts from Pimcore Studio, or schedule them to run without an open browser.

Search all registered console commands and inspect their arguments/options.
Run commands in the background and see their output and exit code.
Paste PHP directly for pimcore:run-script.
Schedule one-time, hourly, daily or weekly executions.
Edit, enable/disable/delete plans and inspect the latest output and status.
Persistent run history with input/output snapshots, filters and pagination; running executions can be closed and reopened from history, and the tab header shows how many are active.
Reusable command templates with input fields, inline PHP and opt-in read-only object previews.
Multi-step workflows that run commands in the background and stop at the first failure.
Schedule a workflow as a fixed snapshot, with per-step progress in the run history.
Configurable Studio action buttons for templates/workflows, with user/role grants and fixed element context.
Global export clients with encrypted, write-only credentials, field mappings and provider connection tests (Shopware).
Optional interactive Linux terminal with administrator-only shell sessions in Studio.
Administrator configuration and CSRF protection on mutations; editors can run explicitly approved Studio actions.

Security disclaimer
Requirements
Install
Direct execution
Command templates and run history
Scheduled executions
Workflows
Failure notifications
Background worker
Studio action buttons
Export clients
Interactive terminal
Languages
Development
Further reading
Inspiration disclaimer

Security disclaimer

Use this bundle at your own risk, especially in production environments. It allows administrators to execute console commands, arbitrary PHP code and, when enabled, an interactive shell in your application's environment. Incorrectly configured administrator accounts or permissions, compromised accounts, and unsafe commands or scripts can pose significant risks to the entire system, including data loss, disclosure of sensitive information and service disruption. Grant administrator access only to trusted, qualified users, review commands and scripts before execution, and maintain tested backups before using the bundle in production.

Requirements

Platform	Pimcore core	Studio UI / Backend	PHP
2025.4 LTS	`^12.3`	`^2025.4`	8.3 / 8.4, as supported by your Pimcore release
2026.x	`^2026.1`	`^2026.1`	8.4 / 8.5, as supported by your Pimcore release

The PHP code supports Symfony 6.4 and 7.x, including Symfony 8.x CSRF tokens in newer host projects. Pimcore Platform 2025.4 uses core 12.3, rather than a core version named 2025.4. CI tests the PHP dependencies and the frontend SDKs (Studio 2025.4.0 and 2026.3.2) separately; a full application smoke test runs in the development project on Pimcore/Studio 2026.3.2 (CI does not provision a Pimcore database).

The compiled frontend ships with every tagged release (and therefore with Composer distributions), so installing the bundle does not require Node.js. It is built by CI on the release tag; the default branch keeps only sources. The optional interactive terminal is the one part that needs Node.js at runtime (22+, on Linux, running as a non-root user).

Install

Until the package is submitted to Packagist, add this GitHub repository to the host project:

composer config repositories.command-center vcs https://github.com/Waaatza/pimcore-command-center-bundle
composer require watza/command-center-bundle:^0.8

The current 0.9.0-rc.1 is a pre-release: it is published as an unstable draft, may still change and is not selected by a stable ^0.8/^0.9 constraint. Install it explicitly when you want to test it:

composer require watza/command-center-bundle:0.9.0-rc.1

Watza\CommandCenterBundle\PimcoreCommandCenterBundle::class => ['all' => true],

Then install assets and clear the application cache:

php bin/console assets:install --symlink public
php bin/console cache:clear

Open System → Command Center in Studio as a Pimcore administrator. Routes are loaded through Pimcore's bundle routing; the frontend uses the configured Studio API prefix. No database migration is needed.

The interactive terminal is disabled by default and needs its own service; see Interactive terminal to enable it.

Direct execution

Choose a command. Arguments/options are a JSON array, with one string per CLI token:

["some-argument", "--limit=10"]

Use [] for no arguments. Commands are executed without a shell and without interactive prompts, with a five-minute process timeout. Environment, ANSI output and interaction flags are controlled by the server.

Starting a direct, template or action run only queues it: the request answers immediately with the run ID and status Queued, and a background worker executes it. The dialog polls the run and shows output and exit code live, so closing it does not stop the execution — reopen the run later from Run history. Direct executions therefore need the worker to be running.

For pimcore:run-script, paste code in the PHP field, with or without the opening <?php tag:

<?php
$listing = new \Pimcore\Model\DataObject\Listing();
$listing->setUnpublished(true);
$listing->setObjectTypes([
    \Pimcore\Model\DataObject::OBJECT_TYPE_OBJECT,
    \Pimcore\Model\DataObject::OBJECT_TYPE_VARIANT,
]);
echo 'Objects: ' . $listing->getTotalCount() . PHP_EOL;

The script runs in an initialized Pimcore environment and its temporary file is deleted on success or failure. Inline scripts accept --dry-run, verbose and quiet options; do not supply a script filename.

Command templates and run history

Templates turn a configured command into a small form: text, integer and choice fields substitute into the JSON argument tokens, so recurring tasks can run without editing JSON. A template whose command has a registered preview provider also shows the affected objects before execution. Templates using pimcore:run-script can store inline PHP source, which is executed unchanged and recorded with the run.

Run history records every new execution (direct, inline, scheduled, template and workflow runs) with status, trigger and a snapshot of input and combined output, plus filters and pagination. Only the last 1 MB of output is kept per run; an unfinished record becomes Interrupted when read after ten minutes, and history has no automatic expiry.

See Run history and command templates for field syntax, storage, the CommandPreviewProviderInterface example and retention details.

Scheduled executions

Configure the command in the Direct execution tab, switch to Scheduled executions, and save a name, first execution and recurrence (one-time, hourly, daily or weekly). Each plan stores its own copy of the arguments and PHP code and keeps its latest result. See Scheduled executions and the background worker for editing, timezones, storage and retention.

Workflows

The Workflows tab chains 1–20 commands into one background run. Steps run in order and the first failure stops the run: its exit code and error become the result, later steps are marked as skipped, and every step is also recorded as its own history entry. Run now only queues a snapshot of the definition, and Schedule workflow creates an ordinary schedule that stores a fixed copy of all steps (read-only afterwards). See Workflows for queued execution, scheduling, history and interruption recovery.

Failure notifications

Choose active Pimcore users and E-Mail, Studio-Benachrichtigung, or both per schedule. Failed and worker-interrupted runs notify the recipients; successful runs do not. See Failure notifications for channels, delivery and permissions.

Background worker

Every execution — direct, inline PHP, template, Studio action and workflow runs — is queued and executed by a background worker, together with scheduled plans. Keep it running in the host application's environment:

php bin/console messenger:consume scheduler_command_center --memory-limit=250M --time-limit=3600

See Scheduled executions and the background worker for a Docker Compose example, heartbeat and locking details.

Studio action buttons

Configure individual template/workflow buttons in Command Center → Studio actions. Place them in the left Studio rail or object, asset and document toolbars. Grant users/roles access, bind element values on the server and choose confirmation/output policies. New buttons are disabled and admin-only by default. Choose icons with the native Studio icon picker, including custom icon paths. Workflows also support typed input fields, CLI placeholders and JSON inputs for inline PHP steps.

See Studio action buttons for setup, permissions, examples and execution behaviour.

Export clients

The Exports tab stores global API clients for external export services. Credentials are encrypted at rest, never returned to the browser and can only be replaced or removed. Each client also stores ordered field mappings from Pimcore fields to external fields. The current stage supports Shopware with a connection test; queued export runs follow in a later stage. See Export clients for setup, storage and provider extension.

Interactive terminal

The Terminal tab opens a real, interactive shell in the environment that runs the terminal service. It is disabled by default and needs a dedicated Node.js service on the same origin as Studio. See Interactive terminal for configuration, deployment, security and limits.

Languages

The interface follows the Studio user language and includes English and German translations for tabs, forms, actions, status labels and application messages. Dates follow the selected UI language. Command descriptions/output and user-supplied PHP code are not translated.

Development

composer install
composer test
cd assets
npm ci
npm run check-translations
npm run check-types
npm run check-history
npm run check-template-preview
npm run check-terminal
npm run check-studio-actions
npm run build

The default branch contains sources only; public/build/ is generated and is not committed. To release a version, commit the sources (including a version bump in assets/package.json and assets/package-lock.json, and the README's version constraint), then tag and push the tag:

git tag -a vX.Y.Z -m "vX.Y.Z - short summary"    # or -F release-notes.md
git push origin main vX.Y.Z

The annotated tag message is the release: its first line becomes the release title and the remaining lines become the release notes, so list the change points there. The Release Build workflow then installs the frontend dependencies, runs the build, commits the generated public/build/ into the tag, updates the tag and creates the GitHub release. A tag push alone therefore produces a complete, installable release.

For a local path installation in a host project, run the PHP tests against its dependencies:

COMMAND_CENTER_AUTOLOAD=/path/to/project/vendor/autoload.php php tests/CommandCenter/smoke.php
COMMAND_CENTER_AUTOLOAD=/path/to/project/vendor/autoload.php php tests/CommandCenter/schedules.php

The opt-in worker integration check creates a harmless, temporary scheduled PHP script and removes only its own plan afterwards. Run it from a Git checkout or local path installation inside a configured host project with the worker running:

COMMAND_CENTER_AUTOLOAD=/path/to/project/vendor/autoload.php php tests/CommandCenter/worker-integration.php --live-worker

Inspiration disclaimer

This project was inspired by the Job Manager available in the Pimcore Store. It is an independent implementation and is not affiliated with or endorsed by the Job Manager's authors.

Built with AI assistance

This bundle was created with the help of a friendly combination of Codex and opencode: the two assistants worked together on the code, tests, documentation and the many small decisions in between, with a human reviewing the result. Please keep that in mind when reading the code — and enjoy.

MIT licensed. Pimcore and its Studio SDK retain their own licenses.

watza / command-center-bundle

Package info

Security

Statistics