15.15. Fixing the problems caused by other plugins/themes

WordPress is extended by using plugins and themes. However, because plugins and themes use the same environment, it is likely that plugins and themes might break features of other plugins or themes. This section explains why and how these problems occur and how to troubleshoot them.

Sometimes, plugins or themes add their styles and scripts to all of the pages of WordPress. This is basically done by naive developers who are not experienced enough in WordPress. This is very unprofessional because these styles and scripts might break other plugins’ or themes’ features. For example, one theme may inject its style files to every page such that it hides certain elements that are used by a plugin. If a theme uses, for example, item class to hide certain elements while another plugin uses it to not hide elements, that theme clearly breaks the view of the other plugin. In case of scripts, the theme or plugin injecting its scripts to every page might break the JavaScript features of the other plugin. For example, the theme might be listening to button clicks to do something, while the other plugin does something else when the same button is clicked. If the theme overrides the listening behavior, then the plugin clearly cannot do its job. Hence, adding styles and scripts to the pages other than the pages belonging to the theme/plugin is very unprofessional and it causes serious problems.

Another case is that the themes/plugins installed in your WordPress site might use the same third party libraries to implement their features. If the version of the third party library used by two plugins/themes is different, since one of them overrides the other one, one of the two plugins/themes might not work properly. This is one of the biggest problems existing in tools that allow third party plugins/themes to be installed. This kind of problems might be fixed by writing the plugins/themes without using any 3rd party library, by providing features of the plugins/themes over a remote server or by making WordPress use the same third party libraries. For example, all plugins/themes use jQuery, a JavaScript framework, provided directly by WordPress so that each plugin/theme does not load its own version of jQuery. Writing a theme/plugin without using a 3rd party library means a lot of work. Since the developers do not want to reinvent the wheel, they intend to use 3rd party libraries. Providing features of a plugin/theme over a remote server has its downsides as well. Therefore, the problems related to 3rd party libraries exist in the tools like WordPress.

As you can see, some problems cannot be fixed simply. What you can do is to detect the plugin/theme that breaks the features of another plugin. This can be done in two ways. The first one is based on trial-and-error approach. With the other one, if it works, you can directly find out why a feature does not work.

Let’s first look at the first approach, which is based on trial-and-error:

  1. Find out the problem. For example, let’s say a button in WP Content Crawler does not work when you click it. But, you know that it works in Demo. So, something should be wrong in your site.
  2. Now, you should deactivate your plugins and/or theme one by one. After each deactivation, try to reproduce the problem. For the button example, click to that button again. If the button works, then the problem’s cause was the latest plugin/theme you deactivated. If it still does not work, keep repeating this process until the button starts working.

Tip

When deactivating your theme, use one of the official WordPress themes. The reason for this is that all plugins must support official WordPress themes. If the error occurs while there are no other active plugins and while an official theme is active, then the problem is not caused by another theme/plugin. It must be fixed by the plugin.

In the second approach, we will try to find out the problem by looking at the debug file. The debug file is basically a text file that stores errors. When an error occurs in your site, it is written into the debug file so that you can find out the cause of the error. To implement this approach, do the following:

  1. Find out the error. There must be a way to reproduce the error.
  2. Enable debugging in WordPress (See: Debugging errors)
  3. Reproduce the error. For example, if a button does not work, click to that button. If a page does not load properly, load that page in your browser again.
  4. Open the debug file. In WordPress, the debug file’s location is wp-content/debug.log. However, your server might define its own debug file location. If the debug file is not in its default location, then you should find out where the debug file is. You can ask your server’s support team about the location if you did not change it yourself.
  5. The debug file stores the most recent errors at the bottom of the file, while the oldest errors are at the top of the file. Therefore, you should look at the last lines of the file. You should observe the lines and try to understand if the error shown in a line is the cause of the problem about, for example, that button or page.
  6. Because the themes and plugins are stored in their own folders in WordPress, you can easily understand the theme/plugin where the error occurred. For example, the folder of WP Content Crawler is wp-content/plugins/wp-content-crawler. If you see a line in the debug file that shows path of a file in this folder, then the error occurred in WP Content Crawler. However, this does not mean that the error is caused by WP Content Crawler. The error’s cause might be another theme/plugin as explained previously in this section.
  7. You can look at other lines of the debug file to find a clue about the plugin/theme that causes the error.
  8. When you find out the plugin/theme causing the error, you can deactivate it and try to reproduce the error. If the error is gone, then, congratulations, you found out the plugin/theme that caused the problem.
  9. You can send your findings to the developers of the theme/plugin that caused the problem so that they can fix it in the next version of their product.

The second way is more cumbersome, but it helps you find out the definitive cause of the problem. The first approach is the one you go on with for most of the time. Although it does not find the cause of the problem, it helps you get rid of the problem quickly.