Pippin Williamson Interview

Interviews

When it comes to plugins, Pippin Williamson @pippinsplugins needs no introduction. After falling in love with WordPress six years ago, he wrote his first plugin for a client, and released it to the world by popular demand. Forty+ plugins later, Pippin shares the hallmarks of great plugin design and what he’s learned managing a developer community of plugin contributors.

Tell us the story of how you got into working with WordPress — what itch did it scratch then and what itch does it scratch now? How did you get into working on plugins and why do you enjoy it?

My first experience with WordPress was about six years ago. My brother, a prominent 3D modeler and teacher in the Blender 3D community, was running his personal website on WordPress. (Blender is an open source 3D modeling platform). He originally had a friend build him a basic WordPress theme but soon realized he wanted a more unique look and additional features, custom-built for his site. I had been into web development for about a year and was working on a steady stream of client sites. At the time, I was building everything in straight HTML.

When I first started exploring WordPress for my brother’s site, I hated it. I thought, What is the point of all this PHP in the file? What the heck is a template file? I don’t know PHP! Luckily I didn’t quit right then because shortly after that first experience, I fell in love with the system.

After realizing I really enjoyed working with WordPress, I began building all of my client sites on it. I felt as though I had this insane power to create anything (realistically I was creating only sub-par websites) and it drove me to continue building my business throughout college.

I used WordPress purely as a platform to build client sites for about a year, at which point I accidentally stumbled into the world of plugin development. A client wanted a special feature that allowed him to upload custom fonts, so I built the feature into his theme. I later wrote up a tutorial on how I did it. Dozens of readers requested that I turn the feature into a standard plugin, but I had never written a plugin nor did I even have an idea of how they worked. After coercing myself, I got over my fear of the unknown and jumped in. Turns out creating a plugin was way simpler than I had expected and I soon had Font Uploader available for purchase.

Once I created my first plugin, there was no going back; I immediately became an avid plugin developer.

You’ve got nearly 40 plugins to your credit listed at WordPress.org. If you were reviewing a young programmer’s plugin, or let’s say if a developer requests a peer review of a plugin — what are the three most important things you look for that indicate a well-designed plugin?

1. Clean code. No matter how simple or complex the plugin, clean, well-formatted code is one of the most important aspects. A lot of developers would probably not name clean code as one of the most important, but I’m a firm believer that taking the time to produce clean, easy-to-read code makes you a dramatically better developer. First, it makes debugging and enhancing the code dramatically easier. Second, as an extension of easier debugging, clean code makes it easier to spot logic or infrastructure problems in your code. Third, taking the extra time to ensure your code is well formatted forces you to take another look at what you’ve written. A second, third, or fourth look will always result in a better plugin.
2. Compatibility with other plugins and themes. One of the hallmarks of poor plugins is that they often conflict with other plugins or themes. This is usually because the developer has not taken the time to step back and think about how his or her plugin affects the other functions at work in the system. Some plugins will blindly modify post content without thinking about how additional plugins may also be modifying the post content. Some plugins will blindly load their own versions of jQuery without thinking about how other plugins or the theme might be dependent on the default version in WordPress. Keeping others in mind is vitally important when writing quality plugins.
3. Not re-inventing the wheel. WordPress provides a huge number of APIs and helper functions to make the plugin developer’s life easier, yet a lot of plugin developers either choose not to use them or don’t realize they exist. One of the best things a plugin developer can do is become familiar with the tools WordPress Core provides and learn how to use them. Learning how they can make developing a plugin easier, while also learning what their limits are, will save a lot of time in the long run. It will also ensure greater compatibility with other plugins and themes.

Of all the plugins you’ve created in your career, which one taught you the most? What did you learn from building it, bad or good?

Definitely Easy Digital Downloads (EDD). It’s my largest plugin, both in terms of the code base and the number of users, but that has little to do with it. EDD is the first plugin I’ve worked on that has a large contributor base. Not only does it have a really large number of users, it has a lot of developers from around the WordPress community contributing to it. Learning how to transition a plugin from me being the sole developer to being developed by the community was eye opening.

Due to the ever-growing size of EDD’s user base, ensuring that we take extra caution with introducing new features and fixing bugs is vital. When a plugin is small, accidentally deploying a fatal flaw is not catastrophic, but when you have thousands and thousands of users using the plugin to run their business (many making hundreds of thousands of dollars a year or more), the deployment of a fatal bug is detrimental.

The precarious balance of backward compatibility is another aspect that has really been highlighted for me over the last year-and-a-half (the time I’ve been developing EDD). When a plugin is so flexible that power users are customizing large portions of it to best suit their exact needs, we have to be very, very careful about making drastic changes. Change one template file and we could potentially break thousands of sites. Remove one feature and suddenly we have a flood of angry users that liked the feature.

There are so many aspects to large-scale plugin development that just doesn’t come into play with small plugins. It has been a fun and very humbling road.

We couldn’t help but notice that all your plugins listed at CodeCanyon are 100% GPL. Why is the GPL important to you and why do you choose to use it?

I firmly believe that users have the right to do anything they wish with the code they have purchased access to. Whether a plugin has a price tag or is distributed free of charge, the right to use it in any way does not change.

My entire business and lifestyle exists the way it does because of WordPress and its open source nature. Distributing my plugins under any other license would be nothing short of an insult to the platform that has enabled me to be where I am today.