I have experienced this first hand. A plugin is accidentally activated or de-activated in production and it kills off something. Panick on !! Initially but it just needs manual sorting but it’s production. Not good on a live production site? I think it probably happens far too often, and it’s one of those small mistakes that can lead to big issues in performance, security, or even compliance. I wanted a way to bring infrastructure-as-code principles into WordPress plugin management - a controlled, declarative approach to which plugins should be active, where, and under what conditions. So I built the Satori Digital Plugin Activator - a lightweight MU plugin that reads from a JSON configuration and automatically manages your plugin states. 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. Has a manual override for those emergencies Sometimes i know there can be the occasion where automatically deactivating those plugins not configured might also cause issues so there’s a manual override that prevents the activator running. 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. In short: you define the truth in one config file, and WordPress does the rest. There’s other stuff in there like loading order but not as important as above. You can view or use it here: GitHub Repository - https://www.twine.net/signin pdf webdevelopment php wordpress
- Web Developer