One of the things that I’ve been making a much more concerted effort, likely more so than I’ve ever done before, is managing separation of concerns between the classes responsible for interfacing with WordPress and those responsible for working with the problem domain.
For instance, let’s say that you’re working on a plugin and it’s going to communicate with a third-party API. Additionally, this plugin will also offer menus, post types, taxonomies, and so on within the WordPress administration area.
There are two areas of responsibility here:
- the area responsible for generally solving the problem,
- the area responsible for interfacing with WordPress.
You can make the case that it’s important to unit test areas that communicate with WordPress, but I also know these are tried and true APIs that have their own set of tests.
Instead, we should be focusing on unit testing and separating our business logic away from WordPress.
But that’s not the point of this post. Instead, it’s more about a way to potentially lay out a project when a portion of it will be interfacing with WordPress.
Organizing WordPress-centric Classes
I’ve talked about the importance and advantages of namespaces in prior posts so that I won’t dive too deeply into that discussion here.
Instead, I’m interested in talking about organizing files at the filesystem level and the namespace level, so they are cleanly separated into their areas of specialization and so that we can make sure we’re, say, focusing our unit tests (and other testing) on areas that are most critical.
Abstracting Meta Boxes
I like the make sure that my directory and file structure mirror that of my namespaces. Sure, it helps with file organization, but also with a conceptual organization.
That is, if I’m going to be working with meta boxes, then I know I can likely find the meta box files in a directory nested with the parent WordPress directory then within an Admin subdirectory followed by a MetaBox directory.
To that end, what might a set of classes designed for working with meta boxes look like should we write code for them in a re-usable manner? Given what we know about meta boxes, we know we’ll likely need the following:
- an abstract class that defines the post type to which each meta box will be bound,
- two functions for the meta box – one for registering it, one for displaying the content,
- a directory to contain the view or the presentation of the meta box,
- a file that will serve as the said view.
Given the above points, perhaps the directory structure would look like this:
Next, we have code that mirrors this structure. That is, within our WordPress directory, we’d have the Admin subdirectory since the meta box is displayed within the administration area of WordPress, and we’d have the View subdirectory that would contain the file responsible for displaying the information.
This leaves us with needing to create a few classes as listed above. Perhaps the abstract base class would look like this:
Then a concrete implementation would extend the class, and it would look like this:
And finally, the view for the class would contain any markup and template code for rendering information:
This gives us exactly what we need in a well-organized, reusable way to work with meta boxes. It can also be repeated for things use as menus, post types, taxonomies, and so on.
But I digress.
A Word About Unit Testing (with PHPUnit)
As I mentioned earlier in the post, I believe that unit testing classes that solve problems unique to our problem space is important. This means that you’d need to tell your PHPUnit configuration file to exclude your WordPress-centric files.
The advantage to what I’ve laid out about is that this becomes trivially easy. Simply put, you can add this to your phpunit.xml file:
This gives you the ability to focus on writing tests specifically for your problem space all the while making sure you’re writing scalable, maintainable, and re-usable WordPress-based code.