Some tools make projects safer, faster, more maintainable, and more portable. Others do the opposite. So they live on our banned components and practices list.

Not allowed. Not supported. Not necessarily bad! But also not a good fit for our ecosystem.

Disallowed Components, Services, and Practices

Some tools make projects safer, faster, more maintainable, and more portable. Others do the opposite.

This policy explains the components, services, and implementation practices that are not currently allowed or not normally supported in our ecosystem across Web, AI, DO/IT, Marketing, Product Management, and qualifying Coaching engagements.

Disallowed does not automatically mean “bad.” In many cases, it simply means a tool is redundant with capabilities we already provide, incompatible with our environments, too costly to support predictably, too opaque to govern safely, or too likely to reduce quality, portability, or continuity.

Why Some Tools Are Disallowed

We do not disallow tools casually.

A component may be disallowed because it creates unacceptable risk, cost, friction, or unpredictability in the environments we build and maintain. In practical terms, that usually means one or more of the following:

It duplicates capabilities already included in our platforms, hosting, automation, or Care programs
It degrades performance or introduces avoidable infrastructure load
It weakens security, governance, logging, or access control
It complicates maintenance, testing, release operations, or rollback work
It creates unnecessary vendor lock, data captivity, or export barriers
It is under-supported, abandoned, unstable, or poorly documented
It cannot be supported by us at a predictable cost and quality level

This policy exists to protect project outcomes, not to play fashion police with tech stacks. Sometimes the best decision is to use less software, not more.

How We Evaluate Candidate Tools and Vendors

Every candidate component, service, extension, app, integration, model, or vendor is evaluated case by case.

Preference is generally given to tools that:

have credible product histories and active maintenance
demonstrate responsive support and useful documentation
follow platform standards instead of fighting them
support automation, API access, webhooks, or other maintainable control patterns
avoid brittle dependency chains
can be supported by agency-level practitioners at a predictable cost
do not box the project into a dead end on styling, data, workflow, or hosting
can pass our internal compatibility, viability, and quality checks

Preference is also given to tools that help users, not only implementers. Good training materials, strong end-user UX, clean permission models, and clear reporting matter.

Where a third-party tool adds little value beyond what we can implement cleanly in our own code or configuration, we will often prefer our own implementation. That reduces dependency load, lowers long-term care friction, and usually improves portability.

What We Disallow Across All Areas of Interest

Across all of our Areas of Interest, we generally disallow tools, services, and practices that fall into one or more of the following categories:

Duplicate-capability wares

If a plugin, app, or service mostly repeats capabilities already provided by our environments, care tooling, or preferred stack, it is usually a bad fit. Extra layers do not magically create extra value. They often create extra failure modes.

Opaque or weakly governed wares

We avoid tools that make hidden changes, obscure behavior, mutate content or configuration unpredictably, or otherwise make it hard to understand what is happening in the project and why.

Abandoned or poorly supported wares

If release history, support behavior, compatibility history, or documentation quality point to a fragile future, we would rather decline the tool now than bill you later for regret.

Vendor-lock traps

We avoid tools that make migration, export, redesign, provider transition, or future refactoring unnecessarily painful. Portability matters. That principle protects you from overdependence on any provider, including us.

Automation-hostile wares

We avoid tools that fight CI/CD, testing, observability, rollback, access control, release management, or repeatable operations. If a tool requires hand-tuned babysitting forever, it is not helping.

Unlicensed, pirated, or otherwise unauthorized wares

No exceptions. If a component is stolen, cracked, nulled, or otherwise unauthorized, it is out.

Tools that break our support model

Some tools are not integrated into the project itself, but into our ongoing Care processes, service accounts, automation, and managed environments. When a requested component would materially disrupt those patterns, support may be declined, limited, re-scoped, or priced differently.

Platform-Specific Notes and Representative Examples

Different ecosystems create different kinds of trouble. WordPress generates more named examples than most because that ecosystem is enormous, noisy, and highly variable. Other areas are better governed by category-level rules plus selected examples.

The examples below are representative, not exhaustive.

WordPress and Related Web Stack Notes

In managed WordPress environments, the most common trouble categories include backup plugins, caching plugins, image optimization plugins, code-execution plugins, page builders, content-mutating SEO wares, and overlapping utilities that duplicate hosting or infrastructure features.

Representative examples that are commonly disallowed in our managed production and primary staging environments include:

backup wares such as All-in-One WP Migration, BackupBuddy, Duplicator, UpdraftPlus, and WPvivid
caching wares such as W3 Total Cache, WP Super Cache, WP Fastest Cache, LiteSpeed Cache, and Hummingbird
image optimization wares such as Smush, Kraken Image Optimizer, and server-based optimizers that consume local infrastructure labor
code-execution wares such as Allow PHP Execute, Insert PHP Code Snippet, and PHP Everywhere
page builders such as Divi, WPBakery, Visual Composer, Themify Builder, Brizy, and similar tools that are too difficult to optimize or govern cost-effectively
SEO or content-manipulation wares such as Broken Link Checker, Yoast, and similar tools that degrade performance, create unclear content changes, or rely on scare tactics disguised as guidance

Some exceptions do exist. For example, some builders, optimization wares, or diagnostic tools may be acceptable in qualified cases, especially in R&D, QA, migration, or other non-primary environments. Likewise, a tool may be acceptable if specific functions can be disabled cleanly and predictably.

That said, exceptions are not defaults.

Astro.js, Headless, and Front-End Adapter Notes

In headless and hybrid environments, we are cautious about wares that create unclear data flow, write directly into content structures without adequate controls, or make front-end behavior difficult to reason about.

We are especially cautious with:

brittle content connectors
weakly documented front-end adapters
tools that force excessive plugin dependencies
systems that make build behavior or deployment outcomes hard to predict
wares that create avoidable coupling between editorial systems and presentation layers

If a component makes an otherwise clean architecture harder to test, harder to migrate, or harder to hand off, it is probably not helping.

AI Platform and Tooling Notes

In AI work, the main dangers are less “plugin clutter” and more governance failure.

We avoid or tightly restrict:

ungoverned model usage
unsafe agent permissions
opaque wrappers that make prompt, output, or cost behavior hard to control
unsupported checkpoints, extensions, or model-side wares with unclear licensing or provenance
brittle retrieval and grounding setups
tools that cannot be monitored, tested, or tuned in a disciplined way
wares that make human review, rollback, or guardrail enforcement impractical

This is especially important in AI projects because bad choices here can quietly degrade quality while still looking clever in demos. We prefer boring control over exciting chaos.

Marketing, CRM, and Publishing Notes

In marketing and publishing systems, the common risk areas are fragile connectors, hidden sync behavior, unclear attribution logic, poor access governance, and automation that becomes expensive to support once it leaves the brochureware phase.

We are cautious with:

tools that sync data in opaque ways
systems that complicate deliverability, consent management, or reporting integrity
add-ons that create content or campaign changes without sufficient visibility
wares that sharply reduce portability or make account transitions painful

If a tool makes campaign operations faster in the short term but harder to govern in the medium term, that is not a bargain.

DO/IT, Access, and Infrastructure Notes

In infrastructure and operational work, disallow decisions often relate to access, recovery, logging, secrets handling, vendor sprawl, and release control.

We are especially cautious with:

unsafe access methods
unmanaged service-account patterns
weak secrets practices
tools that interfere with backup, recovery, or rollback work
wares that complicate logging, monitoring, or emergency response
components that duplicate managed infrastructure services while reducing reliability

A project can survive a lot of bad taste. It survives far less bad infrastructure.

Unlicensed, Pirated, and Nulled Components Are Not Allowed

We will not install, approve, or support nulled, pirated, cracked, or otherwise unauthorized components for any reason.

This applies to plugins, themes, scripts, templates, extensions, desktop wares, SaaS seats, AI-adjacent wares, checkpoints, and similar assets where licensing or authorization is required.

In the most benign cases, such wares simply steal from their authors. In less benign cases, they also introduce malware, hidden calls, data theft, backdoors, legal exposure, or support nightmares.

If a project under our care is found to include unauthorized wares, we may require immediate replacement, suspend related support, or remove the affected component from supported scope until the issue is resolved.

This is not negotiable.

If a Newly Disallowed Component Already Exists in Your Project

This policy is a living document. A component that was acceptable during implementation can later become disallowed.

That can happen because of abandonment, security issues, licensing changes, compatibility failures, vendor behavior, upstream provider restrictions, or changes in platform standards.

If that happens, we will assess the issue and present a practical path forward. Depending on the situation, that may include:

a direct replacement
a phased migration
a temporary containment plan
a support waiver with modified coverage
a proposal for fixed-scope remediation
or, where fixed pricing is not realistic, hourly work governed by clear approvals and pace controls

When a replacement is required, we will explain the reasoning plainly and offer options that are as predictable and commercially sensible as possible.

Exceptions, Waivers, and Risk Acceptance

Some projects become dependent on tools that are no longer a fit, or that never should have been in the stack to begin with. In rare cases, an exception may be possible.

When an exception is granted, it is usually narrow, time-bounded, environment-specific, and documented. It may also require one or more of the following:

a change in Care cost
a change in support coverage
exclusion from some guarantees or response commitments
a timeline for removal or migration
documented responsibility splits between teams or providers
restrictions on where the component may run

Not every disallowed tool can be waived. Some must simply go.

Also important: many ongoing care capabilities depend on our own internal processes, managed service accounts, automation, and environments. Where a waiver or private third-party setup breaks those patterns, the project may still be supportable, but not at the same level, not at the same cost, and not always with the same guarantees.

Need a Ruling on a Specific Tool?

If you are evaluating a plugin, theme, app, extension, AI tool, model provider, integration service, or supporting platform and want to know whether it is compatible with our environments and support model, ask us.

In many cases, the answer is not a simple yes or no. A tool may be:

approved generally
approved only in certain environments
approved only with scope or support limitations
approved only for migration or transition use
or disallowed, but replaceable with a better-fit alternative

We can also recommend substitutes that better fit your goals, your budget, your portability requirements, and your long-term care expectations.

Policy Note

This public page is principles-first and example-based. It is not intended to expose every operational compatibility note we maintain internally, nor to function as a giant public blacklist that must be updated every time the ecosystem sneezes.

The purpose of this page is simpler and more useful:

To show you how we think, what we protect, and why some tools are welcome while others are not.

- - -

Why ban?

We don’t ban anything that we don’t absolutely need to exclude from our environments. And banned wares are not necessarily bad; they may simply not be compatible with our goals, which are all about supporting your goals in the most cost-effective and high-quality manner possible. Favored wares can become banned if and when they become incompatible with these goals. And banned wares can and do unban if and when they meet our compatibility and quality goals.

Some of the components we exclude are disallowed by our data centers, development tooling services, or other partners and providers. Some have been found to be incompatible with our own internal standards and practices, such as our various automation tools or implementation recipes. And, of course, some are banned because of quality or security concerns. Whatever the case, if you'd like to use a component that we do not support, we can work together to find viable alternatives.

Minimum fitness standards for themes and plugins

While plugins and themes are evaluated on a case-by-case basis, we do also have standards for evaluating the fitness of plugins and themes that are not already disallowed by our data centers or other upstream service providers. This part of our Banned Components and Practices Policy approves candidate plugins and themes that meet the following minimum fitness measures:

Candidate plugins and themes should have a free version that is available on the WordPress directories (plugins, themes), and:
1. Free directory versions must evolve alongside any available premium version
2. Free directory versions must not behave or perform at levels that are significantly different or lesser than their premium versions
Or, if candidate plugins and themes do not have a free directory version:
1. Candidate must include free trials of appropriate length (as required to prove compatibility and quality within each applicable project)
2. Candidate must include appropriate developer support even during the free trial
All candidate plugins and themes (whether they have free directory versions or not) must have positive product histories:
1. Release histories demonstrate high developer involvement
2. Support histories demonstrate responsiveness to user concerns and requests
3. Issue histories demonstrate stability, security, and compatibility with WordPress Core and applicable components on our recommendations list
Candidate plugins and themes should not require other plugins or themes to run (dependencies), other than plugins or themes that are part of the same product suite that the candidate represents, unless:
1. Plugin or theme dependencies meet the same minimum fitness measures described herein
2. Plugin or theme dependencies do not require additional dependencies of their own (multi-level dependency chains are not allowed without special waivers that limit support and guarantee coverage)
3. Plugin or theme dependencies must be supportable in all free and premium versions, where applicable
Candidate plugins and themes must not include functionality or style that is difficult to override.
Candidate plugins and themes must be documented thoroughly enough to enable agency-level support to end users at a predictable cost (extra points to candidates that also include documentation and training for end users).
Candidate plugins and themes must pass our internal compatibility and quality checks, including:
1. Ongoing Viability Testing
2. Project-specific testing (as applied to current projects we maintain that include the candidate plugin or theme)

Beyond the above requirements, preference is given to candidate plugins and themes that also:

Include API's, webhooks, or other features that enable automation
Provide training materials for end users
Are priced in a manner that allows projects to include candidate plugins or themes without undue concern about future costs of ownership

While not actually a fitness issue, we do avoid the use of plugins that offer functionality that overlaps with preferred plugins that are already implemented in the project (or are to be implemented).

Finally, if the functionality offered by a candidate plugin is implementable in our own code (in a cost-effective and timely manner), we will generally opt for such an implementation instead of using the candidate. This allows us to reduce third-party dependencies, streamline future growth and maintenance efforts, and improve project quality (performance, security, etc).

Banned WordPress plugins

This list is updated whenever our providers inform us about changes in their own ban lists and when we discover in our own work that a previously unbanned plugin must now be banned, or when a previously banned plugin is now safe to unban.

In each of the below categories, where detail is not specifically provided ahead of the list about our concerns regarding that portion of the list, the reasons are generally the same: Performance risks, functionality or security conflicts, or incompatibilities with our automation.

Administration Plugins

Inactive User Deleter
Plus: ?

Backup Plugins

Daily container backups are included in all of our packages. We also offer additional backup options that include incremental daily, six-hour, hourly, and near-real-time backup options. Since many backup plugins cause performance issues in our finely tuned environments and consume significant bandwidth (thereby risking overage charges), while not actually offering any services that aren't already included or available in our solutions, we ban most by default:

All-in-One WP Migration
BackupBuddy
Backup Guard
BackWPup
BoldGrid Backup
Duplicator
Snapshot
UpdraftPlus
WP ALL Backup
WP DB Backup
WP DB Backup Made
WP Time Capsule
WPvivid
Plus: Any backup plugin that performs non-incremental backups.
Exceptions:
1. BlogVault is allowed and we use it ourselves. However, the use of your own BlogVault account is discouraged as it would increase Care Plan costs. This is unfortunately unavoidable because our license management and update automation can only be applied to our own service accounts, which means that supporting your own private installation would add manual steps to ongoing care and maintenance commitments.
2. VaultPress is allowed by discouraged as it adds no significant capabilities to our existing backup tools. Moreover, as is the case with private installations of BlogVault, the use of VaultPress will unavoidably increase Care Plan costs.

Caching Plugins

As our environments already include object caching and page caching services, most caching plugins actually degrade performance by consuming resources that are not adding any new capability to your project:

Borlabs Cache
Cache Enabler
Comet Cache
Hummingbird
LiteSpeed Cache
W3 Total Cache
WP Fastest Cache
WP-Optimize
WP Super Cache
Plus: Any caching plugin that repeats any of our existing caching or optimization capabilities.
Exceptions:
1. Super Page Cache for Cloudflare is allowed, though the use of the fallback cache system is discouraged.
2. WP Rocket is allowed because we can automatically disable its caching functionality while leaving other optimization capabilities intact.

Code Execution and Development Plugins

Allow PHP Execute
Insert PHP Code Snippet
PHP Everywhere
Regenerate Thumbnails
Styleguide
Theme Switcha
Plus: Any code execution or development plugin that circumvents industry standards for shipping quality and versioned code.
Exceptions:
1. Query Monitor, Theme Check, User Switching, View Admin As, and What the File, are not allowed on any White Glove server (Production and Primary Staging), but are allowed on Super Stagers, RemDevs, and QA servers.
2. WPCodeBox is allowed on Super Stagers, RemDevs, and QA servers in ProDev programs.
3. Log Deprecated Notices and Rewrite Rules Inspector are discouraged on all servers, but allowed on Super Stagers, RemDevs, and QA servers with appropriate support waivers.

Image Optimization Plugins

We provide image optimization features for most projects (rare projects may have specific needs that cannot be met with our existing tools). Our tools will not alter your images (unless you also want optimization of your base images), include lossless and lossy options, and even produce WebP versions that are only served if supported. For these reasons, and others, the following are all disallowed in our environments:

Imsanity
Kraken Image Optimizer
reSmush.it
Smush
WP Compress
Plus: Any image optimization plugins that use our servers for the actual optimization labor (server-based optimizers), and any image optimization plugins that have settings that conflict with our existing tools and that we cannot disable programmatically.
Exceptions: Optimole and ShortPixel are allowed in our R&D environments, but not in most White Glove environments (Production and Primary Staging).

Minification and Optimization Plugins

Performance enhancement features like resource modification, database optimization, and payload compression are already included in all of our environments. If your project requires a form of optimization that we don't already cover and is available in a plugin or service that does not conflict with our services, we will certainly review it. At the outset, however, most plugins in this category are excluded from our service, including:

Better WordPress Minify
JCH Optimize
Optimize Database after Deleting Revisions
P3 Profiler
Plus: Any minification and optimization plugins that perform functions that our tools are already providing, add non-cachable payloads that should otherwise be cachable, or otherwise interfere with our finely tuned infrastructure.

Page Builder Plugins

The following Page Builders are disallowed by default, but some may be considered with appropriate Care Plan exclusion and coverage waivers:

BoldGrid
Brizy
Divi
SeedProd
SiteOrigin
Themify Builder
Thrive Architect
Visual Composer
WPBakery
WP Page Builder
Zion
Plus: Any page builder plugin that is too difficult to optimize cost-effectively or prevents us from controlling user access to builder features (vs native WordPress content editors).
Exceptions:
1. Beaver Builder
2. Elementor
3. Generate Press
4. Oxygen
Possible upcoming exceptions: We are currently evaluating several page builders as viable candidates for the development of Headless WordPress projects. Check back here for upcoming updates on this category of page builders.

Security Plugins

Many security plugins introduce significant performance costs because of the scanning they typically perform. Since all our solutions include DDOS protection, firewalls with configurable rulesets, IP blocking, and more, there is little to be gained from typical security plugins.

That said, we are not currently banning any security plugins, though the "minimum fitness standards for themes and plugins" rules as detailed above do indeed apply. Nevertheless, security plugins in general are discouraged and requests for including them in client projects will be considered on a case-by-case basis.

SEO and Content Optimization Plugins

Search engine and content optimization are important objectives, but there is also a great deal of hype and waste in this area. Too many of the offerings in this category have risky performance costs, or modify content in ways that are not clear or easily predictable. Some even take advantage of the secrecy that necessarily surrounds engine algorithms by providing misleading guidance that is intended to encourage your dependence upon their "wisdom". Of course, not all SEO plugins are guilty of these unfortunate practices, and some actually help quite a bit (our favorites are listed on our recommendations page), but the following are banned in our environments:

Broken Link Checker
Yoast
WordPress Popular Posts
Plus: Any SEO plugins that modify your content without providing complete control and reporting, degrade performance to a degree that is difficult to justify relative to the benefits offered, or engage in scare tactics or fictitious guidance.

Social Media Plugins

WP-InstantArticles (Facebook Instant Articles)
Plus: Any social media that performs poorly, does not allow for failed listings to be styled for consistency with the website, or interferes with caching.

Theme Support Plugins

Pipdig Power Pack (P3)
Plus: Any theme support plugin that is required for theme usage (rather than used as an optional feature enhancement).

Video Compression, Conversion, and Encoding Plugins

Server-based video compression, conversion, and encoding plugins consume heavy infrastructure resources and often require more management and support than can be justified in our fixed-pricing. Therefore, all such plugins are excluded from our White Glove environments (Production and Primary Staging).

Video compression, conversion, and encoding plugins may, however, be considered for use on a case-by-case basis in projects that are homed in our R&D environments.

Ultimately, serious video crunching objectives should be serviced by third-party cloud platforms such as Amazon Elastic Transcoder, Cloudinary, Dacast, Qencode, etc. And, of course, we can wire up such solutions to your project as needed.

Remember that if all you need in video is online storage and playback within your pages, Dailymotion, YouTube, Vimeo, and the like may be all you need, especially since each of these also includes a growing collection of creative and management power tools.

All nulled plugins are banned!

Premium plugins that have been modified (hacked) to allow the use of premium features without the proper license are often known as "nulled plugins". In the most benign cases, these plugins effectively steal from their authors by allowing users free access to features that normally require a fee. In more harmful cases, however, these plugins can also include code that collects information without user permission and even attacks other sites.

Ehven Consultants will not install or approve the installation of any nulled plugins for any reason. Projects that have been granted access to install their own plugins or themes and are found to incorporate nulled plugins, will be required to replace these disallowed wares or risk suspension and eviction.

Of course, all of the same risks and rules apply to nulled themes, as well as nulled plugins.

Banned WordPress Themes

We don't maintain a list of banned WordPress themes, because all of our current and recent projects are built on one of our recommended themes. Even in cases in which clients request a specific theme be evaluated for fitness, we have found that strong developer-friendly themes (of the kind listed on our recommendations page) can do anything that a theme with a pre-crafted design can do. And they can do it in a manner that doesn't box the project into a look-and-feel that is difficult to change down the road.

Toss in a modern page builder (such as any of the builders listed on our recommendations page), if indeed your project is actually likely to benefit from a page builder, and you quickly run out of reasons to use most themes.

Newly banned plugins that are already in use

As this ban list is a living document that is subject to change, your project may include a plugin that was perfectly acceptable during implementation, but that has since been banned.

While following the guidelines in the "minimum fitness standards for themes and plugins" section above should limit the likelihood of such occurrences, abandoned plugins and other changing conditions are nevertheless possible.

Should a plugin in your project become banned after it was implemented while approved, we will assist you in replacing it with an appropriate alternative. As is our practice in all other commissioned work, you will be offered a detailed proposal with fixed and transparent pricing options, as well as enough time to decide how to respond to the banning.

Waiving bans

Under rare circumstances, some projects may become dependent upon plugins that have been banned.

If the banning can be waived, such that all affected teams (hosting, external services, etc) agree to allow the plugin to remain in the project in an activated state, you will be offered the opportunity to sign a waiver that stipulates the following, as required:

Change in Care Plan cost
Change in support coverage
Timeline for the project to free itself from this dependency