A site running one of our themes has two kinds of plugin, and they are different things.
- An integration
A first-party package we wrote, for our themes, usually to replace a general-purpose plugin that does the job badly for them. It is ours. If it misbehaves, that is our bug and our fix.
- A third party plugin
Anything else you install. It is yours: your choice, your configuration, and yours to own when it interacts badly with something.
Everything below follows from that distinction.
#What we build integrations for, and why so few
We use one criterion: how fundamental the tool is. Multilingual, forms, newsletter, cookie consent, search. Few sites avoid all of those, and none of them is going to disappear in a year.
An integration is our own implementation of that job, built to fit the theme, so you are not running a plugin whose styling, markup and settings were designed for somebody else's product.
Niche utilities, widget packs and content extensions are not on the list and will not be, because most of what they do is already in the theme.
#Where responsibility ends
A plugin outside that list is yours to choose and yours to own.
What it does to your speed, your layout and your site is outside our control. We do not take tickets about a third party plugin's behavior, and we do not build a custom integration for one. The rule is the same on every ticket, because it is what you agreed to at purchase.
The authoritative text is on the main site:
We do not claim our themes work only with that list. They are built on standard WordPress and most things work. If a plugin turns out not to work with the theme, that is a fact about the pair, not a defect in our product, and the cost of resolving it sits with the person who chose to install it.
#What you can do about a conflict
There are three options, and none of them obliges us to fix somebody else's plugin.
- Tell support what you found
Within your support window, and with the diagnosis already done: what happens with the plugin active and deactivated. If the fix turns out to belong in our code, we want it, because that is our bug. If it belongs in the plugin, its author is the only person who can make it.
- Ask for it as a feature request
If what you want is for the theme to support that tool properly, that is a product decision rather than a bug. It is judged on whether it would serve everybody using the theme, with no promise and no date attached. Sending a feature request covers where it goes.
- Ask for paid customization
If you need it working on your site specifically, and soon, that is work rather than an answer. It is quoted and paid separately from support, and custom work explains how that is arranged.
#What not to install
We describe signs here rather than names, because names change and signs do not.
All in one collections. Hundreds of widgets and features in a single plugin, of which you will use three. All of it loads, and any of it can break.
Plugins with no updates for years, low ratings, few installs, or bought from questionable marketplaces. That last one matters most: cracked copies of paid plugins are the most common way malicious code arrives on a WordPress site.
Plugins that duplicate what you already have. A second caching plugin, a second SEO plugin, a third block pack. Two plugins doing one job conflict with each other.
In current WordPress, most needs are covered by the block editor and by what already ships with the theme. Install a plugin when you know what is missing, not in advance.
#Practical checks
Before installing, check when the plugin was last updated, how many active installs it has, and whether the author answers on its support forum. All of that is visible on its page in the plugin directory, and the plugin handbook sets out the standards those authors are measured against.
After installing, check page speed and walk the site. A plugin that costs you a second is worth knowing about on the day you added it, not three months later.
At any strange behavior, deactivate third party plugins first and check again. That single step separates a theme problem from a conflict faster than anything else, and it is the first thing support will ask you for.
#Common questions
A plugin I need conflicts with the theme. What now?
Diagnose it first: confirm the conflict by deactivating everything else, and note exactly what changes. Then send that to support inside your window. If the cause is in our code we fix it as a bug. If it is in the plugin, only its author can fix it, and we will say so rather than take the ticket further. If you need it working regardless, that is paid customization.
Can I ask you to add an integration for a plugin I use?
Yes, as a feature request. It is a product decision judged on whether it would serve everybody using the theme, so there is no date and no promise attached to it.
How many plugins is too many?
There is no number, because ten light ones can cost less than one heavy one. The useful test is whether you can say, for each plugin, what it is for and what would break if it were gone. A plugin you cannot answer that for is one you are carrying rather than using, and it still loads code, ships updates and can conflict. In practice, a site with more than about twenty plugins is usually carrying several of those.
Do your integrations count toward that?
They are plugins too, built for this theme and tested with it, so install the ones whose features you use and leave the rest. The difference is that a conflict between two of ours is our problem to solve.
I am unsure about one specific plugin
Install it on a staging copy and compare. Ten minutes there answers the question better than any recommendation can.
#Still stuck
Open a support ticket and say what you tried and where it stopped. Your product, your domain, a screenshot and the exact message you saw are usually enough to settle it in one reply.
Last updated
