Identifying Plugin Issues

11 min read Updated

When Page Builder or another SiteOrigin plugin stops working, a conflict with another plugin or your theme is the first thing to rule out. It’s the test we ask for on the support forum: keep the SiteOrigin plugins active, deactivate the rest, and if the problem goes away, reactivate the others one at a time until it returns.

Back Up, Update and Clear Caches First

Back up your files and database before you change anything. Check your hosting account for a backup option. Then install the available updates at DashboardUpdates and check whether the problem remains.

An old cached page can still show the problem after you fix it. Before testing, clear your caches and check your browser:

  • If you use a caching plugin, clear its cache and then deactivate it. Keep it off while you test the other plugins, then activate it last.
  • If your host has a server cache, clear it in your hosting control panel.
  • After each change, reload the page without the browser cache: Ctrl+Shift+R on Windows, or Cmd+Shift+R on a Mac (Cmd+Option+R in Safari).
  • If the problem shows in one browser but not another, turn off that browser’s extensions and check again.

While other plugins are off, visitors lose the features those plugins provide, such as forms or checkout. Test on a staging copy if your host offers one, or at a quiet time. If the problem also shows while you’re logged in, you can use Troubleshooting Mode to test without changing what visitors see.

Step 1: Deactivate All Plugins Except SiteOrigin Plugins

Keep Page Builder, the Widgets Bundle and any other SiteOrigin plugins active. Deactivate the others.

  1. Go to PluginsInstalled Plugins.
  2. Click the checkbox in the table header to select every plugin.
  3. Click the checkbox next to each SiteOrigin plugin to remove it from the selection.
  4. In the Bulk actions menu, choose Deactivate and click Apply.
  5. Check the problem again: repeat the action that failed, such as opening Page Builder.

All plugins selected with Deactivate chosen in Bulk actions

If the problem is gone, you have a working baseline: a setup where the problem doesn’t happen. Go to Step 2.

If the problem is still there, test your theme next.

Plugins listed under Must-Use on the Plugins screen stay active during this test. Hosts add them for caching and security, so if you suspect one, ask your host how to disable it.

Switch to a Default Theme

Switch to Twenty Twenty-Five, the default WordPress theme, to see whether your theme is involved. Keep only the SiteOrigin plugins active.

  1. Go to AppearanceThemes.
  2. Hover over Twenty Twenty-Five and click Activate. If it isn’t installed, click Add Theme, search for Twenty Twenty-Five and install it.
  3. Check the problem again.

Twenty Twenty-Five on the Themes screen with the Activate button

If the problem is gone now, you have a working baseline. Go to Step 2.

If the problem is still there with the other plugins off and Twenty Twenty-Five active, the plugin conflict test has failed. Go to If the Test Fails.

Step 2: Reactivate Your Theme and Plugins One at a Time

If you switched to Twenty Twenty-Five, start with your theme.

  1. Activate your own theme again and check the problem. If it comes back, your theme is involved. Reactivate your plugins and report the result.
  2. Go to PluginsInstalled Plugins and click Activate under one of the plugins you deactivated.
  3. Reload the page without the browser cache, then check the problem again.
  4. Repeat with one plugin at a time until the problem comes back. The last plugin you activated is the suspect.

If the problem stays gone after you reactivate every plugin, note the updates you installed and the caches you cleared. If it returns later, run the test again and note which plugin brings it back.

When you switch to the default theme, widgets that have no matching widget area in it move to Inactive Widgets. When you reactivate your theme, check that your menus and widgets are in place.

Reactivate in Groups

If you have many plugins, you can reactivate them four or five at a time.

  1. Click the checkboxes next to the plugins in one group.
  2. In the Bulk actions menu, choose Activate and click Apply.
  3. Check the problem. If it is still gone, repeat with the next group.
  4. When the problem returns, deactivate that group.
  5. Reactivate its plugins one at a time and check the problem after each plugin. The plugin that brings the problem back is the suspect.

Step 3: Confirm the Conflict

Some problems need two plugins together. To rule that out, leave only the suspect and the SiteOrigin plugins active:

  1. Deactivate every plugin except the SiteOrigin plugins and the suspect.
  2. Check the problem.

If the problem comes back with only the suspect and your SiteOrigin plugins active, you have confirmed the conflict. Deactivate the suspect, reactivate your other plugins and report the result.

If the problem stays gone, keep the suspect active and reactivate your other plugins one at a time. If another plugin brings the problem back, note both plugin names and the order you activated them. Deactivate one of the two, reactivate the rest, then report what happened. If the problem never returns, report that result too.

If the Test Fails

If the problem is still there with every plugin except the SiteOrigin plugins deactivated and a default theme active, the plugin conflict test has failed. The problem doesn’t come from another plugin or your theme, so Steps 2 and 3 won’t help. Stop the test here, then reactivate your own theme and your plugins.

Next, post the problem on the support forum and let us know the conflict test failed, so we know where not to look. While you wait for a reply, look for an error message using the steps outlined in Debugging in WordPress.

Test in Your Own Session with Troubleshooting Mode

Troubleshooting Mode turns off plugins and switches to a default theme for your session only, while visitors keep seeing the site as usual. Changes you save still affect the live site. If you still see your usual theme after you enable Troubleshooting Mode, clear your caches and reload the page.

Use the standalone Troubleshooting plugin for these steps; it uses Twenty Twenty-Five for the theme test. Health Check & Troubleshooting offers the same mode.

  1. Go to PluginsAdd Plugin and search for Troubleshooting. Install and activate the result by Marius L. J., even if another plugin appears first.
  2. Go to ToolsSite Health and open the Troubleshooting tab.
  3. Click Enable Troubleshooting Mode.
  4. In the admin bar, open Troubleshooting Mode > Plugins and enable your SiteOrigin plugins. Then check the problem. If it is still there, the test has failed: disable Troubleshooting Mode and go to If the Test Fails. If it is gone, you have a working baseline.
  5. In the Troubleshooting Mode menu, open Themes, switch to your own theme and check the problem. If it comes back, your theme is involved: disable Troubleshooting Mode and report the result.
  6. If it stays gone, enable your other plugins one at a time and check the problem after each plugin. The plugin that brings the problem back is the suspect.
  7. To confirm it, use the Troubleshooting Mode menu to turn off the other plugins. Leave the suspect and your SiteOrigin plugins active. Check the problem again. If it comes back, you have confirmed the conflict: note the suspect and report it after you leave Troubleshooting Mode. If it stays gone, enable your other plugins one at a time to find the second plugin involved.
  8. When you finish, choose Disable Troubleshooting Mode in the same menu. Logging out also ends it.

The Troubleshooting Mode menu in the admin bar listing plugins to enable one at a time

Must-use plugins stay active in Troubleshooting Mode. If the page still shows its old version after you clear your host’s cache, ask your host to turn off that cache during the test.

If You Can’t Log In to wp-admin

If a plugin error locks you out of the dashboard, WordPress shows a message that starts “There has been a critical error on this website.” When the error happens in the dashboard or on the login page, WordPress also sends a recovery link to your site’s admin email address, with a subject ending in “Your Site is Experiencing a Technical Issue”.

The link opens the login screen in recovery mode. Log in, and WordPress keeps the plugin that caused the error paused for your recovery session. Go to PluginsInstalled Plugins, deactivate that plugin, then click Exit Recovery Mode in the admin bar.

If you can’t use the recovery link, rename the plugins folder instead. WordPress can’t load a plugin it can’t find, so it deactivates the missing plugins the next time you open the Plugins screen. Here’s how to do it in your Hosting File Manager.

  1. Log in to your hosting account and open the File Manager.
  2. Open the folder WordPress is installed in, such as public_html, then open wp-content.
  3. Right-click the plugins folder, choose Rename and rename it to plugins-off.
  4. Log in to your WordPress dashboard and go to PluginsInstalled Plugins. WordPress shows a notice for each plugin it deactivated, ending in “Plugin file does not exist.”
  5. Back in File Manager, rename plugins-off to plugins. Your plugins return to the Plugins screen, all deactivated.
  6. Activate your SiteOrigin plugins and check the problem. If it is gone, go to Step 2; if it is still there, switch to the default theme.

Renaming the plugins folder to plugins-off in cPanel File Manager

Open the Plugins screen in step 4 before you rename the folder back. That visit is what deactivates the plugins; without it, they all load again.

If you already know which plugin is at fault, rename only its folder inside plugins, for example example-plugin to example-plugin-off. If your theme is the cause, rename its folder inside wp-content/themes. The next time you open AppearanceThemes, WordPress switches to Twenty Twenty-Five, if it is installed.

Renaming one plugin folder to turn that plugin off

If you use SFTP, connect with a client such as FileZilla or Cyberduck and rename the plugin or theme folder described above.

Report the Result to SiteOrigin Support

If the conflict involves a SiteOrigin plugin or theme, tell us what you found and we’ll look into it. Users of our free plugins and themes can post on the SiteOrigin support forum. If you have SiteOrigin Premium, email us at the address on our Contact page. Include:

  • The steps that show the problem, what you expected and what happened.
  • The plugin or theme that brought the problem back and its version number. If you ran Step 3, include the result.
  • Whether you tested with Twenty Twenty-Five. If you did, include the result.
  • Any error messages you saw. Debugging in WordPress shows how to find errors in the browser console and in debug.log.
  • Your site information. Go to ToolsSite Health, open the Info tab and click Copy site info to clipboard. The copy lists your WordPress, PHP, theme and plugin versions and leaves out your database details. It includes your site address and server paths, so read it before you post it in public.

If another plugin is involved, share your test results with its author too.

Ask an AI Assistant

Your AI assistant can help you decide which plugin to test first and make sense of your results. Follow the steps above, and check its conclusions against your own test results. Before you paste anything, remove passwords, keys and customer details. Never paste wp-config.php.

To plan a conflict test, copy this prompt and replace the words in capitals with your details:

I have a WordPress site with a problem I think is a plugin conflict.
The problem: DESCRIBE WHAT HAPPENS AND WHERE.
It started after: THE LAST CHANGE YOU MADE, IF YOU KNOW IT.
Active theme: THEME NAME.
Active plugins: PASTE THE PLUGIN NAMES.
I will keep the SiteOrigin plugins active and deactivate the rest.
Suggest an order for reactivating my other plugins. Group them if
that saves time, and tell me what to check after each change.
Ask me questions if you need more detail. Do not suggest editing
core WordPress files.

To make sense of your results:

I ran a WordPress plugin conflict test. With only the SiteOrigin
plugins active, the problem was GONE OR STILL THERE.
Theme test: TWENTY TWENTY-FIVE FIXED IT / DID NOT FIX IT / NOT TESTED.
It came back when I activated PLUGIN NAME. With only the SiteOrigin
plugins and PLUGIN NAME active, it was THERE OR GONE.
What does this show, and what should I test next?

To write the support request:

Help me write a support request about this WordPress problem.
Keep it short and factual, with steps to reproduce, the expected
result and the actual result.
My notes: PASTE YOUR NOTES AND THE VERSIONS FROM SITE HEALTH.