You have probably heard somebody say that it is impossible to write proper, professional software with WordPress. If not, at least somebody has implied how WordPress is not a professional tool and that real software developers would not use it.
They are all wrong. You can write great code and WordPress is not stopping you.
This series of posts will not explain in detail what are the principles of great code and what are the benefits of writing such code. But if you already know about them, it will teach you how to apply those principles in the WordPress world.
Great code?
So what is this great code? For me, it starts by not being procedural. Most of WordPress itself and its plugins is procedural. That kind of development style quickly leads to messy code, if you write more than just a couple of functions.
You want your code to be clean, easy to understand, testable, with minimum amount of dependencies within components, reusable, extendable… and conforming to all the other principles of great code. You can do all this in procedural code. But these things are way easier if you write object-oriented code.
Tools we use
To do all this fast, you need tools. Here are the tools we use to build applications on WordPress:
(1) Bedrock WordPress Stack is a stack of tools and a project structure. The most significant thing that it comes with is (2) Composer. Composer is a dependency manager, meaning you get to define the third party requirements your application has and Composer will get them for you. You give up automatic updates from within WordPress, but for proper software development and maintenance process you should anyway.
Composer comes with (3) an implementation of PHP autoloading. Autoloading loads files that contain classes right when you need them. There is no need to litter the code with require and include statements. Autoloading requires you to name the folders and files according to a strict standard, which in itself is a good thing. Folders match the namespace names and file names match the class names they contain.
There are some very common types of classes we write. Probably the most common type is a class that represents a custom post type. Custom taxonomies, Posts 2 Posts connections and query filters are other common types. To help with that, we have created (4) WPlinth, a collection of base classes and other functionality. It helps with writing testable code in other ways too: there is a simple mechanism to easily mock WP_Query and other core WordPress classes without using a wrapper.
As part of WPlinth we have adopted and modified (5) Loopable Query to let us interact with WP_Queries with foreach loops and not all that boilerplate code you normally have to deal with. Turns out that makes mocking the monstrous WP_Query a lot easier, since in many cases you can use an array to do the job, and in worst cases you need to cast that array as an object.
We use Symfony framework’s (6) DependencyInjection Component. Dependency injection helps to write code that is not dependent of specific implementation of other functionality. We define our application class configuration as a yml file and could easily switch the implementation of parts of the application without actually touching the code.
For writing the actual tests, we use (7) PHPUnit. To help with WordPress specific testing we use (8) WP_Mock.
Every tool I mentioned above, except of course Bedrock, is available as a Composer package.
In the next post we will delve into actual code and more details of our setup.