Bringing Infrastructure-as-Code Discipline to WordPress Plugin Management

If you’ve ever accidentally activated a development plugin like Query Monitor, or left a caching plugin running on a staging environment, you’ve probably felt the pain of plugin chaos.

In most WordPress projects, plugin activation is a manual process — inconsistent, error-prone, and disconnected from version control. It doesn’t have to be.

The Problem
When you manage multiple environments (development, staging, production), keeping plugin states aligned can be tricky. A single missed deactivation or version mismatch can introduce security issues, performance hits, or environment drift.

The Solution: Satori Digital Plugin Activator
The Satori Digital Plugin Activator brings declarative control to WordPress plugin management. Using a single plugin-activation.json file, it enforces exactly which plugins should be active, where, and when.

Each environment can define its own plugin group — staging, production, or custom — and the activator ensures that only those plugins are running in that environment.

Key Features

Automatically activates required plugins
Enforces your declared plugin list at runtime, ensuring consistency between environments. Each plugin entry can define version requirements, load order, and whether activation should be deferred.

Deactivates anything not listed
Keeps production lean and secure by removing any plugins not defined in your JSON configuration — no manual cleanup required.

Handles version checks and compatibility rules
Validates plugin versions using semantic comparison (e.g. >=2.1.0). Logs mismatches, prevents activation of unsupported versions, and can deactivate outdated ones automatically.

Supports environment-based groups (staging, production, development)
Each group can declare its own plugin set and target URL, ensuring the right tools run in the right place — dev tools in staging, performance plugins in production, etc.

Integrates with WordPress hooks and settings
Allows conditional activation: load plugins only when a specific option is set or a hook fires (e.g., after_setup_theme or init), giving you fine-grained control over when and how plugins load.

Fully compatible with WordPress 6.8+ and PHP 8.3
Built with modern PHP syntax, tested under current WordPress standards, and structured using single-responsibility classes with unit and integration coverage via Pest.

Infrastructure-as-Code for WordPress plugins
Define, commit, and deploy your plugin states as configuration. No more guessing what’s active — every environment reflects exactly what’s in source control.

How It Works
On load, the activator reads your JSON configuration, evaluates plugin states, and applies changes:

• GroupActivator merges environment-specific plugin definitions.
• PluginActivator checks versions and handles activations/deactivations.
• FilterActivator and SettingsActivator handle conditional logic.
• ActivationUtils keeps everything consistent and version-safe.

It’s built for WordPress 6.8+ and PHP 8.3, using clear separation of responsibilities and full test coverage with Pest.

Why It Matters
This approach treats plugin configuration as code — meaning it’s version-controlled, reproducible, and aligned with DevOps workflows.
You’ll never have to wonder “Is that plugin supposed to be active here?” again.

Explore the project and full documentation:

GitHub: Satori Digital Plugin Activator