Translated by Núria Adell.
I won’t get tired of repeating this. The world of web development is a jungle where no matter how experienced you are, any specimen can mess up your work. If this is what you do, you’ll know what I’m talking about. Doing evil is easier than it seems. And unfortunately, at Nelio we’ve already encountered more situations than we’d have liked where our plugins have stopped working because of the bad practices of third parties.
One of the most common problems you can find nowadays if you develop plugins for WordPress is the misuse of JavaScript. Many “developers” (to call them somehow elegant) don’t follow the rules of WordPress. And you can find unexpected surprises. Or even worse, your customers will find them ?
In this article I’ll explain how we spent a morning investigating the problem that a client of Nelio Content had and how we managed to solve it thanks to an extension for Google Chrome and Opera that streamlined the whole process.
Investigating JavaScript issues in a “hostile environment”
The story begins as usual: a client contacted us through our support system because he had problems with Nelio Content. In particular, the problem had to do with the analytics that Nelio Content provides. In his installation, the analytics page of Nelio Content was loading infinitely, showing nothing further.
After requesting access to his WordPress (it’s not always easy to get access to your clients’ installations) and checking the error ourselves, we saw that there was indeed a problem related to our scripts. But it was a very strange problem. Apparently, we had an infinite loop of calls to functions. Functions that are only executed in response to events. So, somehow, events were being generated multiple times without making any sense.
Investigating these types of problems in a client’s installation is hell. In addition, we were unable to reproduce the problem in our local development installations. So every change we had to make in our JavaScript code meant that we had to test it on our development installation, prepare a new version of the plugin (a .zip file), disable the uploaded version in the client’s website and delete it, upload the new version there, and finally activate it and see if we had solved the problem.
It’s clear that if you get FTP or SSH access everything is simplified, but that was not the case. You won’t always be able to have an environment where testing is plain sailing. So every test we did wrecked our productivity and patience. And besides, nothing indicated where the problem was. What were we doing wrong?! Until the little lightbulb lit up…
What if the problem you have with our plugin is not really a problem with our plugin? Could there be another plugin that puts something in our page and makes everything break down? Let’s investigate…
As you should know, if a WordPress plugin defines a private page on the WordPress Dashboard, this page (usually accessible through the plugin menu) belongs to the plugin, and no one should put any JavaScript or CSS style there. This is what the standards say, but the reality is very different, unfortunately.
In our client’s WordPress installation, on the Nelio Software analytics page, we found more than 10 JavaScript files that weren’t part of our plugin. Remember that this page is private, so no one, except Nelio Content, should put anything in there ?
In these cases, you usually deactivate the active plugins and see if the problem is solved simply by having only Nelio Content active. From there, if everything works, you activate a plugin at a time to see which is the one that is breaking yours. However, being in front of a WordPress installation in production, you can’t do this recklessly or you might make the website of your client break down by disabling plugins.
Luckily, we finally found the solution.
The extension Request Interception allows you to replace scripts and styles with your own. In addition, it works on both Google Chrome and Opera. Take a look here. And its interface is very simple:
You just have to write the URL of a remote file and replace it with any other URL. This way, we could find all the paths of JavaScript files that weren’t from WordPress or written by Nelio Content by exploring the source code of the analytics page of Nelio Content.
Once you’ve found these URLs (more than 10, in our case), you can put them in the Interception extension and have them replaced with a URL from your local installation. We ended up with something like this:
You can see that all the URLs were replaced by local URLs that point to a specific JavaScript (empty.js in the screenshot above). That JavaScript does nothing inside in order to “deactivate” the other (let’s call them intercepted) JavaScripts. And you don’t have to worry about things failing since the original scripts shouldn’t be on those pages.
Once you’ve done this, you’ll see that the content of those scripts is replaced with your empty.js file. You can check it by looking at the browser developer’s console:
Now that you’ve intercepted conflicting scripts in your browser and “disabled” them locally (remember that this only happens in your browser, your client’s installation is still working as usual), you can check if your plugin works. In our case, the problem disappeared, so the only thing left was figuring out which plugin was the cause.
For this, you only have to eliminate the substitution rules of Interception one by one and testing them to see when the problem reappears. Once you find what JavaScript of another plugin is breaking yours, you have the culprit.
In the case of our client, the causal plugin indiscriminately added a JavaScript in all the pages of WordPress. This JavaScript was also throwing events in selectors with no sense, so it drove the filters of the analytics page of Nelio Content crazy.
We contacted the developers of the plugin causing the problems (WP Social Traffic PRO, which isn’t in the WordPress directory, but is sold on an external website) from several means, but we haven’t received any response. The client was reported on the problem and asked to disable the conflicting plugin, since it could break not only Nelio Content, but other plugins with selectors.
And so far the story of how we spent a morning in Nelio until we came up with the solution thanks to Interception.
Nelio Content
I’m so happy about Nelio Content that I will sound like a payed advocate… but here’s why you’ll love it: it works as promised, its auto-scheduling feature is top-notch, Nelio’s value for money is unmatched, and the support team feels like your own.
Panozk
Conclusions
Each plugin for WordPress should only put JavaScript files and CSS styles on its own pages or on common WordPress pages. An example of a common page is the page for editing posts. If you’re going to put a CSS or a JavaScript there, do so keeping in mind that you can break the work of others. Be careful and be responsible.
Unfortunately, many plugins skip the previous rule for no reason. Many times it’s because of ignorance or inexperience of the developers. At least, that’s what I’d like to think. If you’re a WordPress developer, please read the Plugin Handbook. Seriously, do it. I’ll leave the link here one more time.
When a client has a problem, we tend to think that we’ve messed up and focus too much on finding what we’ve done wrong. This is one of the mistakes that, at least in my case, I tend to commit very often. And sometimes, as in the story I’ve told you, it’s someone else’s fault. Had we looked at this before, we would have come up with the solution much sooner. Of course, don’t go too far thinking that mistakes are never your fault. Just keep in mind that this happens, and check it out to try to improve your productivity.
As a client, be careful in terms of where you get the plugins you install in your WordPress. Try to look up for information beforehand and verify that the source can be trusted and the developer is experienced. Otherwise, you’re risking it. The WordPress plugin directory is usually the best place to look at. But that doesn’t mean you can’t find plugins of dubious quality there too. Again, be careful.
The plugin review process should include certain automatic checks. This way you could avoid (or minimize) the enqueueing of styles and scripts indiscriminately. It’s feasible. I won’t get tired of asking for this. Why is the theme review more open than that of plugins? At Nelio we’d love to contribute by reviewing WordPress plugins.
The Request Interception extension is absolutely wonderful. If you know more tools like this that can help you in your day to day as a developer, please don’t hesitate to leave a comment explaining your case. We’d love to learn from your experience.
Featuring image by Alexander Dummer in Unsplash.
Leave a Reply