Plugin Management Standards & Approval Process

Uncontrolled plugin installation is one of the primary causes of WordPress site instability, performance degradation, and cascading errors. These standards exist to prevent plugin bloat and ensure every addition to a site is intentional, justified, and maintainable.

Core Rules

Approval Required

All new plugin installations must be approved by Mark before being added to any site. This applies to every environment — production and staging alike. If you need a plugin, request it via email or Google Chat. Do not install first and ask later.

"Nobody ever can install a plugin unless it's one of our standard plugins, unless I tell you that it's okay." — Mark Hope, 2026-01-29 standup

Paid Versions Only

Always use the paid version of a plugin, never the free tier. Free and paid versions of the same plugin behave differently at a code level — different file configurations, different database behavior, different performance characteristics. The paid version represents the developer's actual investment in quality and stability.

Minimum Footprint Principle

Choose the plugin that covers exactly the features you need — nothing more. A plugin with 100 features where you need 2 means 98 features running in the background, consuming resources and creating potential conflict vectors. Evaluate plugins on fit, not feature count.

Risk-Reward Assessment

Before installing any plugin, the account manager should have an explicit conversation with the client covering:

What business value does this feature deliver? Can the client articulate a concrete benefit?
What is the risk? Every plugin makes the site slower and more fragile. The client should understand this trade-off.
Is the juice worth the squeeze? If the client cannot justify the business benefit relative to the added complexity, do not install it.

If the client insists on a feature after understanding the risk, document that conversation and proceed. If they cannot justify it, push back. Clients will generally accept a simpler, more reliable site when the trade-off is explained clearly.

Scheduling Apps — High-Risk Category

Scheduling and event management plugins (e.g., Bookly, Event Manager Pro) are a disproportionate source of site instability and should be treated with extra scrutiny.

Avoid feature-rich schedulers for simple use cases. A client who needs a basic "pick a time to meet" widget does not need a full-featured booking platform.
Do not install multiple scheduling plugins on the same site.
If a scheduling tool is required, agree on a single approved option internally before recommending it to the client. Test it in an isolated environment and evaluate database growth relative to actual usage.

Evidence from the field: every site with an event scheduler plugin has shown instability. Bookly and Event Manager Pro running simultaneously on a single site produced tens of thousands of lines of code for a feature that needed two.

WooCommerce Sites — Elevated Risk

WooCommerce sites carry inherently higher plugin risk due to the ecosystem's size and the frequency of version compatibility issues. Specific guidance:

Resist incremental plugin additions driven by client feature requests. Each addition compounds fragility.
When a client requests a new WooCommerce feature, first explore whether it can be achieved through native WooCommerce configuration or a design change before reaching for a plugin.
Plugins that conflict with WooCommerce (e.g., third-party donation plugins) should be removed and the functionality rebuilt using WooCommerce-native constructs where possible. See ^[1] for a worked example using variable-price products as a donation replacement.

What Happens When You Don't Follow This

The consequences observed across the managed site portfolio:

File bloat: Disabled plugins leave files and database entries behind. One site accumulated 6,000 orphaned files; another had 1.4 million database entries from a single activity monitor plugin.
Caching conflicts: Multiple plugins attempting to handle the same function (image compression, lazy loading, page caching) conflict silently and intermittently — the kind of bug that only appears when you're not watching.
Performance collapse: WP Engine scores dropped to 15/100 on affected sites. Cache hit rates fell to 10% against a target of 85%+.
500/502/504 errors: Plugin-driven server overload caused error rates of 20–30% on some sites.

Cleanup Protocol for Existing Sites

When auditing a site for plugin bloat:

Identify all installed plugins — active and inactive.
For each inactive plugin, delete it (not just deactivate) and run a database cleanup tool to remove orphaned entries.
For active plugins, confirm each one has a clear owner, a documented purpose, and is on the approved list.
Check for duplicate functionality (two image compressors, two lazy loaders, two caching layers) and consolidate.

Any plugin removal or database cleanup on a production site should be coordinated with Mark. Do not restore a backup to recover from a plugin-related break — fix the underlying issue. See ^[2] for the full backup policy.

^[2]
^[3]
^[4]
^[1]