Conflicts in WordPress and How to Overcome Them

Written by Eduard | Front End Jedi

WordPress is a complex ecosystem where a lot of different types of applications coexist with an infinite number of combinations of plugins, themes, and customizations. This is very powerful and gives a developer a lot of freedom to build whatever they need while using all the pieces they might need.

Yet anyone who has worked in this environment knows that at the same time, it can be a very painful struggle, where, just like in chemistry, a wrong combination of ingredients can be fatal.

When developing a plugin designed to be used in a large community like WordPress, the potentially chaotic conflicts that are possible has to be on your mind at all times. The goal then is to create a plugin that doesn’t conflict with any of the millions of different permutations of environments that can be installed.

The purpose of this article is to analyze and find a solution specifically for the conflicts relative to using other plugins as vendors in the plugin you’re developing for WordPress.

Example

In this example, we start from the idea that we want to create a plugin that loads different templates depending on whether the user agent is mobile or desktop.

We could implement a class called DeviceDetection that from one user agent can detect if it's a mobile or not, but in a large community with a lot of contributors, it's easy to find different options that have already solved that problem, are well tested, and well maintained. So, why reinvent the wheel?

Therefore, imagine we have a plugin called DEVICE_DETECTION. Using it should be as easy as having the source files in our vendor directory and:

A potential problem regarding conflicts here could be that another plugin uses the same require in the same execution. In that case, the class would be loaded twice and our site would crash. Not desired, really.

But we could avoid that using namespaces:

Example 2

The problem now is that maybe some other plugin is using a different version of the DeviceDetection and we are loading their version. Maybe in their version, the is_mobile method had a different name, so we would crash. Better, but we would still be having conflicts in some environments.

We need to find a solution to isolate ourselves from the rest, even if the class is from another plugin — we need to make the external plugin be only ours.

The way to do this is to create our own namespace, in that case, we would be the only ones loading that particular class and nobody would conflict with us.

For example:

This implies that we need to refactor all files in the DeviceDetection plugin to follow that pattern. We have to do it in a way so that every time they update the module, it's not a pain in the ass for us to upgrade to the newest version. Forget about one time refactor; this has to be automatic and as transparent as possible.

Using the composer at build time to execute a script to refactor seems to be the right approach:

The script has to replace all usages (uses, namespace declarations, aliases, etc.) to use the new namespace.

An example of how to give all files of the vendors a prefix to be used only by your plugin should look like this:

This way, every time we do a build using the composer, after downloading all vendor plugins we’ll automatically refactor them so they are safe to be used anywhere and are conflict-free with different versions of the DeviceDetection plugin.

With this solution we are able to:

• Avoid version conflicts
• Isolate the vendors from the original
• Easily update vendors
• Perform an automatic refactor.

Hope this helps other developers make a better, conflict-free WordPress environment.