Being a WordPress plugin developer is kind of insane when you think about it. You write code that can be freely modified by anyone and is expected to work with any infinite different collections that make up a unique WordPress site. This is a huge part of why I love what I do, but still, I have to admit, it’s kind of crazy.
Developing a plugin or theme that has to be compatible with a range of different WordPress versions, PHP versions, MySQL versions, web servers, and more is a huge undertaking. That doesn’t even include the infinite number of combinations of plugins that any one environment may have.
Free software, like free speech, is messy. Both can get ugly, and both require personal responsibility and strong communities to make it work.
If you’ve attended a WordCamp or read a forum or frustrated blog post about WordPress, you’re probably aware of update complications, the infamous white screen of death, and plugin and theme compatibility issues.
Users have every right to be frustrated by these issues, and their frustration is very real. But, at the same time, as a community we need to do a better job of managing user expectations.
WordPress promises a five-minute install. WordPress also makes it easy for anyone with a minimum amount of training to put together a very complex combination of different bits of software to create a special and unique system.
I’m not criticizing the fact that people without a technical background use WordPress or create sites for others without knowing a lick of code or having a fundamental understanding of how the application they configured works.
On the contrary, I think it’s really great. It’s a huge part of how our work empowers others.
It Just Works
WordPress itself is very secure, but it’s unreasonable to expect that WordPress will continue to be as secure once you start adding plugins and themes and executing random code snippets that you copy and pasted from some forum on the Internet.
Most WordPress developers create plugins and themes “the WordPress way” in hopes that they’ll be compatible with one another. But we can’t test our work against every single plugin out there, with every theme, on every host… It’s totally unrealistic. I haven’t even mentioned all of the multipliers and it’s already an insane matrix of possibilities.
Still “it just works” is the myth that WordPress is selling. People turn to WordPress to do important things — which include sharing personal stories, promoting important causes, selling their products, and more. When WordPress doesn’t work properly it stands in the way of someone doing their job, selling their product, or telling their story.
Configuring The User
In many ways, we are setting users up to fail. Many plugins, including some of mine, have installation instructions like this:
- Upload `plugin-name.php` to the `/wp-content/plugins/` directory
- Activate the plugin through the ‘Plugins’ menu in WordPress
I’m quoting directly from the sample WordPress plugin readme file on WordPress.org. While that is technically correct — assuming that wp-content is the name of the end user’s content directory — they’re not necessarily the best instructions. It assumes the user will test locally, do situational testing with error reporting fully enabled for PHP and JavaScript, and then deploy to staging for review and approval by others.
I’ve done a lot of plugin support, and it’s incorrect to assume that an end user knows how to build a local or staging environment, enable WP_DEBUG, or even open their JavaScript console.
This is a terrible assumption. Then, once they have a problem, we ask them to do all these things. We ask them to turn off all other plugins and switch to the default theme after their website is already live when doing so would just break it even more.
There is no easy solution to this and my criticism is delivered on a stone from inside my glass house. We can all help to bridge this gap in knowledge by including suggestions on troubleshooting and disclaimers imploring users to test locally first (and providing the resources on how to do so) on our websites.
Local testing, debugging, and other useful skills may seem like mastery to be learned later, but they are fundamental in configuring users to be proactive, and to increase their overall satisfaction with WordPress and WordPress products.
Don’t Get Frustrated, Start Educating
Frustrated users, who have been let down by WordPress, or by a specific plugin or theme often times results in frustrated developers.
But, we, as plugin developers, need to take a step back and empathize with our users. We need to remember that their frustrations are grounded in a real issue — whether it’s an unreasonable expectation, a bug, or something else. Whatever it is, WordPress has gone from a tool to meeting a goal to a barrier. Whatever the source of frustration, defusing irritation starts with empathy.
The more we educate users about why WordPress plugins and themes are created — I think WordPress.org can do better to not present plugins and themes as free tools that magically appear on the Internet — the more users can empathize with plugin and theme developers.
It’s much more challenging to control the reactions of frustrated users than it is to control your own reactions. We can, however, educate users in our documentation or in the plugins themselves on what to expect and how to get help.
Nothing Is Foolproof
WordPress isn’t fool proof, and there’s no magic bullet to this issue. The fun thing about what we do is that the better we get at it, the more complex our problems with it become. But by improving education, setting more reasonable expectations, and, most importantly, being more empathetic to users, we can make the whole process more civil and less frustrating for everyone.
6 Comments