One of the most successful features of WordPress is that it has been able to encourage a community of developers that extend the basic functionality of this content management system through the creation of plugins. That and the fact that the WordPress market share has not stopped growing in recent years is key to attract talent.
WordPress plugins are the best. Knowing that if you need to customize your website you can do so by just looking for a plugin that does what you need gives you peace of mind. And it also reduces costs a lot.
Not having to (in most cases) develop custom solutions is a relief. It democratizes access to complex websites for a fraction of the price they would cost a few years ago.
But not everything is a bed of roses. When selecting a WordPress plugin we have to be very careful. WordPress’s popularity attracts talent. But it also attracts less experienced developers who sometimes create plugins that don’t have the desired quality levels. Detecting them is not as easy as counting the number of positive ratings they have or how many sites they are installed on. It’s much more complex.
Something we have suffered in Nelio since we started analyzing WordPress installations of our customers is the amount of trash we can find installed there. We’ve seen things you wouldn’t believe…
That’s why today I’ll explain some of the most common and curious problems we’ve encountered over these years with WordPress plugins.
WordPress Plugin Problems List
Here I leave you with the list of problems you can find with WordPress plugins. They are generic problems and we will not give specific names of plugins that suffer from them, but they do exist and you have to be careful to avoid them.
Create Additional Tables in The Database
The WordPress database is a war zone. Many plugins extend it to add their own tables. This doesn’t have to be wrong, but most of the time it’s not necessary.
The WordPress database is generic enough to not have to add new tables for your plugin to use. So why does a developer see the need to add more tables to WordPress? The answer is quite easy: comfort and ignorance.
Many times it is easier for someone with little experience in WordPress to put additional tables and make queries directly in SQL to read and modify data. This, in addition to being a security hole if not done well, you avoid using meta tables.
If you want to extend user information, you have the wp_usermeta table. The same goes for the contents (wp_postmeta), comments (wp_commentmeta) or even taxonomy terms (labels and categories, with the wp_termmeta table).
WordPress provides methods to read and modify this meta-information in a standard and secure way. Unless you have a performance justification, dear WordPress developer, don’t use additional tables in your plugins.
Nelio A/B Testing
I was very impressed by the quality of this plugin, how easy it was to set up, and the outstanding support Nelio provides. I highly recommend Nelio A/B Testing.
Josette Millar
Load Bad Scripts And Styles
Most WordPress plugins will sooner or later need to load their own JavaScript and CSS files, sometimes in the WordPress admin panel and sometimes on the front of the web. And the sad thing is that this is something that is often done wrong.
To add a CSS style or a JavaScript file in WordPress you have to enqueue it in the standard WordPress queue. To do this, first register it with the functions wp_register_style and wp_register_script, and then enqueue it with wp_enqueue_style and wp_enqueue_script, respectively.
Note that these functions allow you to define the dependencies that your styles and scripts have, so WordPress manages the dependencies correctly and enqueues only what you need.
Anything else is wrong. And here even the developer documentation is to blame. Look at the examples that come in the wp_head hook in the WordPress Codex. Developers will take this as a reference, and then what happens is that they break things ?.
Don’t even think about using wp_dequeue_script or wp_dequeue_style to dequeue scripts or styles from WordPress. Many times we’ve seen how plugins dequeue the version of jQuery that comes with WordPress to add their own (which is usually outdated) and from there everything stops working…
If you detect a plugin that does not load scripts and styles correctly following WordPress guidelines, this is a reason enough to disable it from your installation right now.
Not Cleaning The Database When Deactivating The Plugin
This is another classic aspect of WordPress plugins, and perhaps the most common you’ll find. In order to work, WordPress plugins will need to add records in your database. The problem here is that when you deactivate the plugin, it is common for those records to remain in your database tables forever.
WordPress plugins dn’t usually erase the data they create in your database when you deactivate them. And no, there is no garbage truck that passes by from time to time and takes this useless data with it.
A WordPress plugin should remove the additional tables that it has created and the data that it has added into the standard tables when the user deactivates it. But it happens very rarely. I encourage you to go to your database and keep an eye on it. Surely you’ll find useless garbage there.
If the developer is careful, deactivating the plugin in your WordPress will ask if you want to deactivate it temporarily or permanently. The latter option will erase all the data that it has been adding during its operation, thus taking out the garbage to leave everything clean.
Not Providing User Guidance
When you install a WordPress plugin and activate it, you usually expect a new menu to appear on the WordPress Dashboard where you can find the plugin’s functions. But this is not always the case.
There are times when the new plugin adds a menu within an existing menu, usually the Tools menu or the Settings menu. So the user will have to investigate to see where is the menu that includes the new plugin just installed and activated.
It is usually a good practice to describe in the README.txt file of the plugin what is going to happen once you activate the plugin in your WordPress. This way you reduce the user’s anxiety and make life a little easier. Otherwise, if the user doesn’t find where are the functions that the plugin adds, they will end up deactivating it, and as a developer that’s the last thing you want to happen.
You may think that this is something that only happens to to newbies. But that’s not the case. Recently, I installed a certain plugin to do certain thing (I remind you that I was going to avoid giving names ?), and I found myself in this same situation. I couldn’t find where the plugin settings were. And if it happens to me, who is supposed to have been working with WordPress for a long time, this same situation is terrible for someone with less experience.
Changing The WordPress User Interface
WordPress is easy to use, or so they say. And an important part of this is thanks to the user interface that WordPress includes by default. This interface is simple in a new WordPress installation, but it gets more complicated ase we add more and more plugins.
In addition, a common problem with WordPress plugins is that they sometimes use a completely different user interface than what users expect to find on the WordPress Dashboard.
I know, the WordPress user interface is somewhat boring from a designer’s point of view, but sometimes it’s much smarter to follow the same styles and the same user experience that your users are used to than opting for a totally different solution.
In our plugins we try to maintain the same WordPress styles and put every element of the user interface where we believe the user expects it to appear. But we’ve seen many plugin interfaces that look little or nothing like WordPress, confusing users.
The recommendation is that if you are the designer of a WordPress plugin you follow the WordPress style guides, and even reuse the components that it now provides to create interfaces in React, exported directly from the Gutenberg block editor. We’re using them in the renovation we are doing of Nelio A/B Testing and they’re great.
Trespassing The Limits of Your Property
The WordPress Dashboard has two distinct types of zones from a developer’s point of view. On the one hand we have the private areas, which are those pages that a particular plugin adds. Within these zones, only CSS styles and scripts included by the plugin to which those pages belong should be enqueued.
On the other hand, we have the common areas, which are all those that come by default in WordPress. Examples of common areas are the content editor, the menu or widget editor, the settings, etc.
Well-programmed plugins, those that follow the WordPress guidelines, will enqueue scripts and styles that affect their private zone only. This means that when they enqueue these resources, they have a condition in the code to check wether they are trying to do it on a private page of their own property or not. Otherwise, they will not enqueue anything outside that scope.
Unfortunately, there are many plugins that “forget” to include this condition in their code. This causes their JavaScript code and styles to load on all pages at all times, something that can break the other common pages or even the private ones of other plugins.
Detecting it is easier than it seems. If you are using a plugin and its user interface looks broken, it is quite possible that another plugin is putting JavaScript or CSS where it shouldn’t and is breaking the styles and behavior of the first plugin. We’ve seen it. It’s happened to us (that they break our interface) and, unfortunately, it will continue to happen.
Not Following Good Programming Practices
You don’t have to be the best hacker in the world to program in WordPress, but a minimum quality when it comes to programming is to be expected.
One of the benefits (if not the greatest) of WordPress is its open source philosophy. Exploring the source code of plugins is something you can always do (at least those plugins in the official repository).
You may find everything: code that’s nice to see and code that will make you cry. And that doesn’t mean that one is worse than the other from a performance point of view. But if you see well-documented, well-indented code and also structured following a logical distribution of files and folders, you have found the holy grail.
If the code of a WordPress plugin is good to see, it’s probably because the programmer is careful and polished. That is a clear sign of quality.
Opening Security Holes
A WordPress plugin is nothing more than a set of code instructions. Usually PHP and JavaScript, that extends the functionality of WordPress. This code will quite safely get data from the user and end up rendering information on the screen.
It is possible that when getting data and printing it on the screen you are adding security holes if you do not process that data correctly. WordPress places a lot of emphasis on validating and sanitizing the input data and escaping the data on output.
There are lots of functions to validate the data and make sure that what the user inputs to the plugin is really what we want, and thus avoid code injection. If the plugin developer does not use them, it is due to laziness or ignorance. Be careful what you end up installing in your WordPress or you’ll end up regretting it.
Performing Unsuitable Activities
Continuing with the previous section, there are plugins out there that come from sources of dubious origin. Sometimes, to save some dollars you dive through dark places on the Internet in search of a .zip file that contains the plugin you want but for which you don’t want to pay.
When you find it, everything is happiness, until you realize that that plugin comes with a gift. From crawlers, cryptocurrency miners, spam, to even malicious code that can take control of your website. You can find everything.
Be wary of the origin of the plugins you find there. The official WordPress repository and the best-known marketplaces are the only reliable source for your WordPress plugins. To be inside those repositories, plugin developers need to pass some quality tests. Trust only known places and avoid plugins obtained from unreliable sources.
Not Adding Value
The worst mistake a WordPress plugin can make is not adding value to its users. As a developer, sometimes you have crazy ideas that you think can be very useful for others. The truth is that if the your plugin brings is very small, the number of users it will end up will be similar.
There are many plugins within the official WordPress repository whose value is low. But this is something that happens in any marketplace or application repository.
If as a developer you want to stand out from the rest of the competition, focus on providing value to your potential users. That way your plugin ends ups gaining the popularity necessary to become a success within WordPress.
Choosing WordPress Plugins is Complicated
Not everything is based on the number of user reviews and on counting stars. Choosing a good WordPress plugin is complicated. There are many hidden surprises that are only discovered by analyzing the source code of the plugin itself. And if you don’t have the knowledge to understand it, be careful.
Look at the comments you’ll find in the plugin support forum inside the repository to see what kind of problems people have with it. Try the plugin in a controlled environment and if you see something weird contact the developer for help.
If after this you are not happy with what you see, look for an alternative. There are thousands of plugins out there waiting for you. Or leave us a comment below. We’re always looking for ideas of new interesting plugins to add to our collection.
Featured image by Goh Rhy Yan on Unsplash.
Leave a Reply