Today, I’m going to show you that plugins should be elegant PHP applications that interface with WordPress.
PHP is still a vibrant and powerful language—even if the discussions on social media & reddit don’t make it sound like it.
It powers roughly 8 out of every 10 sites that use server-side languages, according to W3Tech’s usage statistics.
Unfortunately, there’s a stigma about the quality of PHP and how it’s used in WordPress.
From Toptal (an engineer staffing agency), “WordPress is the most widely used site technology on the planet and with good reason. Yet legacy code in its core is a mess, and this problem cascades to third-party developers. Some developers take this as an excuse to cut corners in their own WordPress PHP code…”
Many WordPress engineers don’t write maintainable and extensible PHP because they don’t feel they can
Why would an engineer focus on writing great PHP code when WordPress itself isn’t a great example of what good PHP is?
I know that I’m painting with a broad brush here, but I think you get the point.
Here are a few examples of WordPress’ shortcomings when it comes to modern PHP
- Lots of functions in the global scope
- Passing around a massive list of global objects (and suggesting their use in the docs)
- Large classes that perform too many jobs
- Procedural (or linear) PHP
But just because WordPress has these shortcomings and issues doesn’t mean that you have to follow their example with your code.
Here’s how you can still write modern PHP in the context of WordPress:
Write Object Oriented PHP following SOLID principles
Object oriented programming is a great way to write extensible, maintainable, and reusable code.
It’s benefits come from a focus on small components or modules that pass data through clearly defined interfaces.
Each piece is only concerned with one thing and, like legos, they fit together to perform a larger function. This larger function is what your plugin should be.
Through writing Object oriented code, your plugin will be faster, easier for others to extend, easier to maintain, and rely less on WordPress’ core methods.
Interface with WordPress
I know that you can’t entirely avoid using WordPress code within your plugin, because there are things (e.g. actions & filters) that are almost requirements.
However, look at your plugin as a full PHP application and therefore you can provide an interface through which you interact with WordPress.
This way, you can map out each part of WordPress and define exactly what you need from it.
Then you can verify that each part your interacting with is giving you the correct response. Doing this, you can rely on this internal API and more easily test your plugin.
Enjoy the process
Writing elegant PHP is enjoyable once you understand its patterns and how they all work together.
Dig in and start learning best practices in PHP and your plugins will be faster, easier to maintain, and easier for others to extend.
Here are a few awesome resources that I’ve found:
- Carl Alexander – Object Oriented WordPress
- Josh Pollock – Refactoring WordPress Plugins
- Refactoring Guru – Modern Software Design Patterns
- WordPress Codex – Plugin Best Practices
- Toptal’s WordPress Development Best Practices
