How to Fix Plugin Conflicts in WP-Admin and Page Builders

Page builders are a very powerful tool to help you set up unique pages, unique layouts, landing pages, and other content outside of the scope of the usual blog post and page format WordPress gives you. Tools like Elementor, Divi, and Beaver Builder are all useful, but they have some drawbacks and risks.

One of the biggest issues I've seen crop up, and one I've experienced myself, is conflicts between these page builders and plugins, themes, and other core WordPress elements.

Diagnosing a Problem

See, page builders are generally built on the assumption that you're using them on more or less a core WordPress installation. If you have any plugins, they are probably all on a list of the top 50 plugins people use for WordPress, so the page builders don't frequently test outside of that kind of environment.

What happens is that there's a conflict between the way plugins work, the way WordPress itself works, and the way page builders typically work.

WordPress has core files, in particular the WP-Admin file, which effectively controls all of the other files in an installation. This is fine, it's how WordPress works, there's no problem here.

Some plugins – a lot of plugins, in fact, more than you might realize – configure themselves to add (or enqueue) assets to WP-Admin. Having all of those assets ready in one place makes the plugin quite fast and ready to fire the instant it's called, which means great performance and smooth operation.

Enqueuing is a supported feature in WordPress, so the platform is designed to handle it. This, too, is pretty much fine. It can be a problem if you have too many plugins, especially if those plugins get in the way of one another, but most of the time, that isn't going to happen.

So, where does the issue come up? When you start using a page builder.

See a lot of page builders give you the ability to load your website as-is and add, edit, and configure pages directly in a WYSIWYG editor. So, you load your site, and you use the page builder to start working, but things aren't working right. There are errors, or some elements don't work, or the whole system crashes.

What's going on? Typically, it's a conflict. Specifically, it's a conflict between the very complex code of the page builders, the complex code of WordPress itself, and the code injections queued into WP-Admin by plugins.

There's no real way for me to say out of hand what exactly is causing the issue because it can be a million different things. It also doesn't really matter if you know what technical reason is causing the problem because none of the possible solutions is reliant upon that knowledge.

Changing Page Builders

Often, one of the first ideas that comes to mind is changing page builders. After all, if you like the plugins you use and you have an issue with a page builder, maybe you want to swap page builders.

There are a lot of options, too:

• SeedProd
• Thrive Architect
• Beaver Builder
• Divi
• Elementor
• Visual Composer
• Themify Builder
• Brizy
• SiteOrigin
• Oxygen
• Spectra
• Cornerstone

It seems like it'd be easy enough to swap, right?

Well, not always. Sometimes, page builders cause problems with your existing pages once you uninstall them. You definitely don't want to have more than one page builder installed at the same time, and they can conflict with each other too. And, if you're paying for a page builder, you don't want to pay for another one and maintain two subscriptions until you figure out which one is having problems.

I will say that if you figure out a specific conflict between a plugin and a page builder, you can report it to the developers of both and see if they want to fix it. That's the best solution, but it's out of your hands, so you have to try something different if you want to fix the problem for yourself.

The Bad Solution

If you read the above and you thought, "It's a plugin issue; I know how to solve that," then chances are you've come up with the same idea most people do at first...

Just disable plugins and test the page builder.

Disable a plugin, try the builder, and see if it breaks. If it does, re-enable the first one, disable the next one on the list, and repeat.

This solution works, but there are several problems with it.

The first is that it's going to take forever. My site has nearly 70 plugins, many of which serve important purposes, and disabling them even for a few hours while I do some work is likely going to make a lot of things look and function a lot worse. Not only do I have to waste hours of my day systematically disabling, testing, and re-enabling plugins, I have to do all of that before I can get any work done, AND I have to make sure I test any new plugins I install since the last time I did it, and any plugins that may have updated, and on and on.

On top of all of that, each time you disable a plugin and do some work, your site is up there, live, without that plugin. What if it's a security plugin, and now you're more vulnerable to DDoS or other attacks? What if it's an anti-spam plugin? What if it's a functionality plugin, and without it, your site doesn't render correctly? What if it exposes files in directories that shouldn't be exposed?

What if Google takes this moment to scrape your site for changes, and now your indexed version of your site has a missing plugin and looks bad, performs poorly, or is broken in some way? Then you're in an even worse bind.

As you can see, it's not a good idea to work on a live site like this. Plus, all of that assumes that you easily identify which plugin is causing the problems. What if there's more than one, so you get through the end of your list, and none of them fixed it?

I recommend testing a local version when possible.A good practice is to maintain a secondary version of your site somewhere, either on a local virtual server or on a remote server, that just has noindexing applied so it doesn't cause issues with your site.

You can use this to test and develop your site, making changes to plugins, layout, and more, without having to disrupt the experience for your users. Think of it like a sandbox.

This is a good idea to have in place, but let's be real: most people aren't going to do it. Maintaining two versions of your site, even if it's relatively easy to mirror with WordPress plugins, is a pain, and you have to be pretty careful with your updates back and forth so you don't overwrite things in the wrong direction.

Anyway, there's a reason I list this as the "bad" solution. Though it might be better to say, impactical, for most people.

Custom Cleanup

The second possible solution involves doing some digging. It's the kind of DIY solution that might be the only one available to you if you don't otherwise know what you're doing (or read the rest of this article.)

You know the problem is, more than likely, in WP-Admin because of code added there by a plugin. You want to keep your solution on your side, in the preview render and not in the live version of your site.

You just need to remove those assets, but to do so, you need to figure out what code in your WP-Admin is added by the plugins. Ideally, you could figure out which code is causing the problem and write a script that can suspend those elements, as well as all the relevant JS, CSS, and other code, and dequeue it in your functions.php file. If you can't figure out which elements are which, you need to dequeue more of them until you find the code that causes the problem.

This solution is better because it doesn't hurt the user experience or put your indexation at risk. But it's still tedious and time-consuming, and it requires that you know enough about PHP to do everything I just mentioned, which certainly isn't trivial. You can use some tools to help – ChatGPT can spit out some useful code, as long as you can audit it to make sure it isn't injecting malware along the way – but honestly, it's just a pain.

The Best Solution: Asset Cleanup

The best solution is the one I just outlined, except it is done by someone who knows what they're doing and can handle it automatically for you.

Fortunately, I know just how to set you up with that, because I did the same thing. Gabe Livan, WordPress expert, created Asset CleanUp Pro to solve exactly this kind of problem.

Asset CleanUp has a lot of useful features, and I make use of a lot of them for site speed and loading purposes. The one most relevant to today's discussion, though, is the plugin manager feature. All you do is configure the plugin to prevent other plugins from loading specifically for logged-in WordPress users. Since the only logged-in users are going to be you, other site admins, and staff, the only people this can possibly affect are the people who it doesn't matter if it affects them.

This way, all you need to do is set up the plugin, and then any time you log in, you'll be able to jump right into editing without other conflicts and issues getting in the way.

Asset CleanUp Pro is also a pretty cheap plugin. The Lite version is free, but the Pro version is only $50 per year for all of the most useful features. It's also one of those plugins where you pay once to get a license key, and you can use it indefinitely, but updates after the first year cost more; it's not updated terribly frequently, so you can often get away with even less if you want.

It's also only $150 for an unlimited license that can be installed on as many sites as you want. I like it for my clients where it's warranted, though not everyone needs it.

Other benefits of Asset CleanUp Pro

I first grabbed Asset CleanUp Pro for the page builder conflict issue, but since then, I've been using it for a lot of things.

By far the best is that you can use it to selectively clean up these plugin code injections across your site, which is a huge benefit for site speed, responsiveness, and functionality.

Let me give you an example. One of the many plugins I use here on Content Powered is a reviews plugin. It gives me the option to put in a shortcode and convert a regular blog post into a review post quickly and easily. It does all the things you'd want it to do, like adding star ratings and infoboxes, adding Schema review markup, and so on.

The problem is, this plugin enqueues its assets everywhere. I mean everywhere. Every page on my site, if you looked at it before I fixed the issue, had a bunch of review code stapled on and ready to be called, even if those pages weren't reviews, or even content pages at all. It was a ton of bloat that just wasn't necessary.

With Asset CleanUp Pro, you can selectively disable this code from being injected on pages you don't want it on.

This also works great alongside one of my other favorite plugins, WP Rocket. WP Rocket has a ton of little features to help speed up a site, and one of the best is some very good caching. To make it even faster, Asset CleanUp strips out all of that unnecessary bloat so that WP Rocket's render, minify, and cache process can cache the cleaned-up page for an even better result. It's one of the ways I keep this site well above 90 on PageSpeed metrics.

All of that is how I've managed to solve the issue with page builders, at least in every instance I've had it happen. It's very rare that a plugin is both essential to the layout of a page (and thus needs to work for the page builder to reflect reality) and causes a conflict with the page builder. It's more often random plugins you wouldn't think are causing the issue, and those are the hardest to figure out.

Fortunately, with Asset CleanUp Pro, you don't have to. Give it a try!