Streamlining a WordPress Build

Through the years I have picked up quite a few techniques and strategies for streamlining the common agency-style website build. We have moved primarily to using WordPress over Drupal because our clients can actually figure out how to update and manage their site without calling every hour. Like Drupal, WordPress is now a fully capable content management system. Also like Drupal, WordPress is littered with legacy code, tightly coupled core methods, global variables and a whole list of open tickets. It’s not perfect, but what it does, it does well. Below I have outlined the major components which a traditional theme is made of.


This part is easy to skip for some folks because of how easy WordPress makes it to get started. The objective is to manipulate the features WordPress gives us in the cleanest possible fashion to make it feel as though the dashboard is actually built specifically for managing that particular site. For this to be done effectively you should take some time and get to know the dashboard and all of the fields it has for you out of the box to make use of so you don’t end up re-inventing the wheel.

Posts, Tags, and Categories

On a major site build I like to leave these dedicated specifically for the blog section for semantic reasons. It’s common for people to separate their content types and sections of the site up by using the categories taxonomy and just have every piece of content simply be a Post. I do not agree with this. There is no reason to cram everything in as a post. We can now make use of custom post types and taxonomies for this. If there is no blog section just leave them alone. Perhaps later down the road the client will find the resources and realize that need to incorporate a blog to drive traffic, and you will be ready. Some people feel uncomfortable with having non-functional aspects to the admin side lingering and that’s normal; I feel the same way. It’s only one line of code to temporarily hide from the dashboard.


Widgets are great for sidebar content and sections of the site that will most likely need to be removed, added, and be re-ordered such as advertisements, recent posts, random snippets of thought, ect. They are quite powerful. I would advise against going widget crazy. I’ve been there, and it’s a trap. Here’s a good rule of thumb; If your layout is dependent on the area you are about to “widgetize”, it’s not meant to be a widget area. Widgets are not reliable to always be at the right place at the right time because they are at the mercy of the client.


I try to keep plugins to a bare minimum and only use them if it makes sense and I absolutely have to. Like widgets, I also avoid tightly coupling a plugin with the theme. A theme should not be dependent on a plugin. They should simply compliment the existing functionality. Like your front-end code, the site should fail gracefully. However, I do have an arsenal of plugins I go to on a regular bases for specific jobs.


The menus addition to WordPress is interesting. In some cases it works great, in others not so much. Once enabled, Menus allows you to easily drag and drop every single page or post of your site to create a custom navigation menu. For creating complex sub navigations dealing with parent and child id’s this can take quite a bit of time wrestling with the raw menu object. There is also an issue with excessively slow save times when the menu becomes relatively large. I find Menus works best with simple navigations such as the footer nav. For the main site navigation I like to create it based on the actual page hierarchy. I also find manually applying the “active” class to the appropriate list-item based on the current page URI works much better then relying on Menus to tell us if the link is the parent or not. Especially on the single content pages.

Streamlining It All

The functions.php is the heart. So I have created a prototype, also known as a boilerplate to give us a solid foundation. It’s called Rye.