At first, this template doesn’t look too bad. However, as soon as you start adding any sort of logic, our markup gets complicated very quickly. In this case, just adding an if statement forces us to use concatenation to create our HTML markup. You can imagine if we needed to add a for loop or other complex logic.

The other thing you will notice is that since our viewmodel is a method we can use it for any other template we need, which keeps our code more reusable and DRY.

Now that we have pulled out the templates from monolithic WordPress template files, we are free to organize our templates using Twig’s elegant include and extend methods. This allows us to organize our templates in a way that supports Atomic Design methodology.

Atomic design helps us keep our templates DRY by creating patterns that are independent and reusable. At Pixo, we organize these templates in such a way that we can attach our CSS styles to them. This helps developers find the related CSS (or, in our case, Stylus) to each template.

Here is an example of how a template directory might look.

You may notice each directory has a config.js file as well. These are configuration files that support the creation of a pattern library with Fractal. Since we have clean, PHP-free, Twig-only templates, we now have the opportunity to use a tool such as Fractal to build out a pattern library of all of our template patterns with very little work.

Up to this point, we have made a huge change to how we create a custom WordPress website. Bedrock has reorganized WordPress to allow for better dependency and configuration management, and Timber has transformed the way we create our theme templates.

Enter Lumberjack.

Lumberjack is another framework that, like Timber, extends the capability of our WordPress custom theme. However, the capabilities it brings are not just limited to theming. Rather than being plugin-based this framework turns your custom theme into a super-charged framework for WordPress development.

Although Lumberjack can be a stand-alone library, the creators suggest it be used with Bedrock. Also, Timber is a dependency, so if you set up Lumberjack as recommended, you will have all the other functionality we have discussed up to this point installed.

Here are some of the other things that the Lumberjack framework supports:

• Creating/registering post-type objects
• WP Query builder
• Registering menus
• Defining custom routes

Let’s start with how Lumberjack helps with custom post types.

Registering a custom post type

The standard way of registering a custom post type is not complicated. You can add some code to your plugin or theme functions.php file that looks like this.

The way we used to do it:

With Lumberjack it looks something like this:

At first glance, this looks pretty similar to the traditional method. You define an associative array with the post-type configuration options defined. However, if you look closer, you’ll see that we now have a separate file for this post type. That is a big win right there because the code becomes easier to find or discover. You’ll notice that this file is called Profile.php and is in a directory called PostTypes. I can now search in my IDE for the very human-sounding “post-type profile,” and it should come to the top of the list. This is another win for Clean Code by making your code easier to read, understand, and discover.

The other thing you will notice is that this custom post type is defined as a PHP object. Also, this Profile class extends another class called Post, which means we can take advantage of inheritance to make our code more DRY.

Query builder

Listing things, like a list of recent blog posts, is a common part of most website projects. Lumberjack comes with a query builder that makes it easier, faster, and more enjoyable to work with the WP_Query functionality.

Here is an example of the traditional way to build a query for a list of projects listed alphabetically by title:

… and here is how to do the same thing with Lumberjack:

First, you’ll notice we didn’t use an associative array to define the query parameters. This is because we are using some very reasonable defaults. Remember the custom post type class we created before. Well, because it extends the Post class, it comes built-in with a builder() method that does the most common kind of query — list a post type (in this case, itself) alphabetically by title. Very smart.

But what if we want to customize the query even further? Well, Lumberjack’s query builder has a set of chainable methods that you can use to extend your query in common ways.

The example below will sort alphabetically by title, exclude post ID 167, and limit the output to the first three items:

You can also query multiple post types by creating a generic QueryBuilder object like so:

On top of this, you can create “scoped queries,” which are defined in a post type’s class and can be extended as needed. This can be useful if you find yourself creating multiple queries with the same base parameters.

A scoped query looks like this:

Registering menus

Just like registering post types, registering menus the traditional way is not difficult. But Lumberjack removes one more hurdle, one more thing to think about. Menus are now a part of configuration.

All you have to do is add a menu machine name and label to an array in the menu config, and you are done. Here is how it looks:

This barely scratches the surface of what Lumberjack can do. I’d encourage you to read the documentation to see all of the features it offers and learn more about how it works.

Advanced Custom Fields Pro is the plugin of choice for adding custom fields to your WordPress project. It is unmatched in its breadth of functionality, longevity, and documentation. However, Advanced Custom Fields (ACF) lacks serious support for configuring fields in PHP code. It is possible to do it, ACF’s website shows you how. There is even a PHP export option in the ACF user interface. But for modern developers, this is not good enough.

This is where ACFBuilder comes in.

At its core, ACFBuilder is an ACF configuration generation library. It allows developers to configure ACF fields using expressive, chainable methods that make it easy to work with ACF in code. Its syntax makes your code more readable while at the same time providing built-in documentation through autosuggestions and other intellisense features offered by any standard IDE. It also provides sane default values for common settings, so you have less code to write most of the time.

Here is a look at the traditional way to register a field group in ACF:

This is very difficult to work with. In order to create this code, you have to either create your fields in the ACF user interface and then export it or pore over documentation on the syntax while writing your code.

With ACFBuilder your field group code looks something like this:

Notice how much easier it is to read. The code is more succinct but it also uses methods that offer meaning as to what they are.

Also, because ACFBuilder is well-written, object-oriented code, it plays very nicely with intellisense features of most IDEs. When defining fields we can start typing method names and get a suggestion of all of the many methods available to our object.

We also get built-in documentation, as you can see below:

The challenge was to bring some modern development best practices to the aging WordPress CMS while at the same time building a better codebase that has the hallmarks of a maintainable, easy to change application.

By implementing a few developer-centric frameworks, we can write more code that works with the powerful features of our IDE, is easier to read, is more reusable, and is just more enjoyable to work with.