One of the most successful features of WordPress is that it has encouraged a community of developers that extend the basic functionality of this content manager through the creation of plugins. That, and that WordPress market share has not stopped growing in recent years is key to attract talent.
WordPress plugins are milk. Knowing that if you need to personalize your website you can do it by just looking for a plugin that does what you need gives a lot of peace of mind. And it also reduces costs a lot.
Not having to (in most cases) develop customized solutions is a relief and democratizes access to complex websites for a fraction of the price it would cost a few years ago.
I’ve seen things you people would not believe. Detect plugins in flames beyond the editor. I’ve seen bugs glow in the dark near the WordPress database. All those moments will be lost … in time … like tears in the rain. It is time to write them.
But not everything is pink. When selecting a plugin for WordPress we have to go with lead feet. WordPress’s popularity in addition to attracting talent also attracts less experienced developers who sometimes create plugins that do not have the desired quality levels. And detecting them is not as simple as counting the number of positive ratings they have or in how many sites they are installed. it’s something more complex.
For this reason today I will explain some of the most common and curious problems we have encountered during all these years with WordPress plugins.
List of plugin problems for WordPress
There are not all who are, but they are all who are. Here you have the list of problems you can find with WordPress plugins. They are generic problems and we are not going to give specific names of plugins that suffer from them, but they exist and you have to be careful to avoid them.
Abuse additional tables
The WordPress database is Comanche territory. Many plugins extend it to add their own tables . This does not have to be wrong, but in most cases it is not necessary.
Main tables of the WordPress database.
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 it is not done well, you avoid using the target tables.
If you want to extend user information, you have the table wp_usermeta. The same goes for the contents ( wp_postmeta), comments ( wp_commentmeta) or even taxonomy terms (labels and categories, with the table wp_termmeta).
WordPress provides methods to read and modify this meta-information in a standard and secure way. Unless you have a justification in terms of performance, dear WordPress developer, you better not use additional tables in your plugins.
Load scripts and styles wrong
Most WordPress plugins will need to load their own JavaScript and CSS files sooner or later, 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 usually done badly.
Loading CSS styles and JavaScript files in WordPress is something that unfortunately, few developers do well, still today.
To add a CSS style or a JavaScript file in WordPress you have to glue it in the standard WordPress queue. For this, first it is registered with the functions wp_register_styleand wp_register_script, and then it is glued with wp_enqueue_styleand wp_enqueue_script, respectively.
Keep in mind that these functions allow you to define the dependencies that your styles and scripts have, so WordPress takes care of managing the dependencies correctly and only glue what you need.
Anything else is to do it wrong. And here even developer documentation is to blame. Look at the examples that come in the hook wp_headin the WordPress Codex. The developers will take this as a reference, and then what happens happens, that things are broken .
Ah! And don’t even think about taking out the flamethrower and using wp_dequeue_scriptor wp_dequeue_styleto decouple the scripts or styles of others. Many times we have seen how plugins undo the version of jQuery that comes with WordPress to add your 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 the WordPress guidelines, this is enough reason to disable it from your installation right now.
Do not clean the database when deactivating
This is another classic WordPress plugin, and perhaps the most common you’ll find. To be able to work, WordPress plugins will need to add records in your database. The problem here is that when you deactivate the plugin, it is usual that these records remain in the tables of your database for centuries to centuries.
WordPress plugins do not usually erase the data they create in your database when you deactivate them. And no, there is not a garbage truck that happens from time to time and takes away this useless data.
A WordPress plugin should delete the additional tables that you have created and the data that you have entered 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 find useless and unusable garbage.
When you deactivate our plugins you will see a dialogue like this, where you can temporarily disable it or delete everything.
If the developer is careful, deactivating the plugin in your WordPress will ask if you want to temporarily disable it or want to do it permanently. In this case, it will erase all the data that has been added during its operation, thus removing the garbage to leave everything clean.
Do not guide the user
When you install a WordPress plugin and activate it, you usually expect a new menu to appear on the WordPress Desktop where you can find the functions of the plugin. But this is not always the case.
If after installing and activating a WordPress plugin you feel that way, the developer has done something wrong.
There are times when the new plugin adds a menu into another existing menu, which is usually the Tools menu or the Settings menu. So the user will have to investigate to see where the nose is the menu that the new plugin that has just installed and activated includes.
It is usually a good practice to describe in the README.txtplugin file what will happen once you activate the plugin in your WordPress. This way you reduce the user’s anxiety and make your life a little easier. Otherwise, if you do not find where are the functions that the plugin adds, it will normally be that you end up deactivating it, and as a developer that is the last thing you want to happen.
Perhaps you think that this is not something where the WordPress plugin is located, something that only happens to the newest. But this is not so. Recently, installing a certain plugin to do a certain thing (I remind you that I was going to avoid giving names ), I found myself in this same position. I couldn’t find where the plugin settings you just activated were. And if it happens to me, which I am supposed to have spent a lot of time working with WordPress, this same situation is terrible for someone with less experience.
Change the WordPress user interface
WordPress is simple 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 newly installed WordPress, but it gets complicated once we add more and more plugins.
In addition, a common problem with WordPress plugins is that they sometimes use a totally different user interface than what users expect to find on the WordPress desktop.
If you are in WordPress, but it does not look like WordPress, you are confusing your users unnecessarily.
I know, the WordPress user interface is somewhat bland from a designer’s point of view, but sometimes it is much smarter to follow the same styles and the same user experience that your users are accustomed to by choosing a solution totally different, no matter how modern or successful.
In our plugins we try to maintain the same WordPress styles and put each element of the user interface where we believe the user expects to appear. But we have seen many plugin interfaces that little or nothing resemble 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 interface. We are using them in the renovation we are doing of Nelio A / B Testing and they are great.
Skip the limits of your property
The WordPress Desktop has two types of distinct zones, from a developer’s point of view. On the one hand we have the private areas, which are those pages that a specific plugin adds. Within these zones, only CSS scripts and styles included in the plugin to which these pages belong should be glued.
On the other hand, we have the common areas, which are all those that come by default in WordPress and that any plugin can access to introduce its functions. Examples of common areas are the content editor, the menu or widget editor, the settings, etc.
If your plugin has broken, it is possible that the blame may have another plugin that is dirtying the styles or breaking your scripts with junk code.
Well-programmed plugins, those that follow the WordPress guidelines, will glue the scripts and styles that affect your private zone only in this private zone. This means that when they glue these resources they have a condition in the code that comes to say that if they are on a private page of their property, they will glue the resource. Otherwise, they will not.
Unfortunately, there are many plugins that “forget” to include this condition in their code. This causes your JavaScript code and styles to be loaded 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 simpler than it seems. If you are using a plugin and its interface looks broken, it is very possible that another plugin is putting JavaScript or CSS where it should not and is breaking the styles and behavior of the first plugin. We have seen it, it has happened to us (to break our interface) and, unfortunately, it will continue to happen.
Do not follow good programming practices
It is not necessary to be the best hacker in the world to program in WordPress, but minimum quality when programming is expected.
One of the benefits (if not the greatest) of WordPress is its open source philosophy. So exploring the source code of the plugins is something you can always do (at least of those in the official repository ).
Being careful programming is noticed by just looking at the code you generate. There is a lot of plugin out there that is worth seeing (from the point of view of its source code).
If you do, you will find everything: code that is nice to see and code that will make you cry. And this does not mean that one is worse than the other from an operational point of view. But if you see well-documented, well-indented code that is also structured following a logical file and directory distribution, you will have found the holy grail.
If the code of a WordPress plugin is a pleasure to see, it is probably because the programmer is careful and polished, which is a clear sign of quality.
Open security holes
A WordPress plugin is nothing more than a set of code, usually PHP and JavaScript, that extends the functionality of WordPress. This code will surely obtain user data and will end up rendering information on the screen.
Most of the time it is unintentionally, but if you do not validate the data and escapes, you are opening more doors than you should to possible attackers.
If you do not do it right, it is possible that when entering data and writing it on the screen you are adding security holes if you do not process that data correctly. WordPress puts a lot of emphasis on validating and sanitizing the input data and escaping the data on the output .
There are lots of functions to validate the data and ensure that what the user passes you is really what it touches 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 will end up regretting it.
Perform inappropriate activities
Continuing with the previous section, there are plugins out there that comes from sources of doubtful origin. Sometimes, to save four euros 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.
We all know it and have we ever done it. To save us four dollars, we went down to the dark areas of the Internet in search of something free.
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 be done with the control of your website. You can find everything.
Be wary of the origin of the plugins you find out there. The official WordPress repository and the best-known marketplaces are the only reliable source to purchase your WordPress plugins. He thinks that being inside those repositories entails passing a series of quality tests in order to remain there. Trust only known places and run away from plugins obtained from untrusted sources.
Not add value
The worst mistake a WordPress plugin can make is not to add value to its users. As a developer, sometimes you have firefighter ideas that you think can be very useful for others, and the truth is that if the value provided by your plugin is very small, the number of users that you will end up having will be similar.
There are many plugins within the official WordPress repository whose value is scarce. 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 adding value to your potential users so that your plugin ends up taking on the popularity necessary to become a success within WordPress.
Choosing plugins for WordPress is complicated
Not everything is based on the number of user reviews and counting stars. Choosing a good WordPress plugin is complicated. There are many hidden surprises that are only discovered when analyzing the source code of the plugin itself. And if you don’t have the knowledge to understand it, they can strain it.
Look at the comments you will find in the plugin support forum inside the repository to see what kind of problems people have with this one. Try the plugin in a controlled environment and if you see something weird contact the developer to help you.
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 are always looking for ideas of new interesting plugins to add to our collection.
