WASP

The Intro

WASP is the label I’ve stuck on my custom WordPress development workflow that I’ve developed over the years with input and collaboration with many friends and colleagues. WASP is an acronym for WordPress, Advanced Custom Fields, Smarty, and Posts 2 Posts.

The Standardization

Over the years, as I honed my skills I began to find a lot of repetition in the work I was doing when it came to custom WordPress site development. I’ve been working with WordPress for about 6 years now and have found a system that works for me and my team. I find myself often needing the same things, some custom post types, some custom structured content for those post types and often times two-way relationships between certain post types.

Custom Post Types

Well, WordPress already has a pretty solid standard for custom post types. The only point I’ll make on this now is that I’ve found it best to keep the theme tidy and create separate scripts for separate tasks. My preference has been to create a post_types sub-directory within the theme, and for each post type, to create a separate script (for example service.php contains the register_post_type function call that sets up the service post type).

Structured Content

The custom structured content it where our first plugin, Advanced Custom Fields comes in. In short, ACF provides a web ui with WordPress to create structured content with custom meta fields. ACF offers a huge range of types (everything from single line text to WYSIWYG to file uploads) and also offer an API allowing developers to build out new field types. ACF allows users to create field groups and assign them to different conditions such as a specific post type or a page using a specific template. Finally, ACF provides a fairly standardized function for retrieving this data within the theme.

There’s a lot more to be said about ACF on their website. If I could offer a bit of advice on ACF usage it would be to strategize your structured content ahead of time, where ever possible assign field groups based on something consistent such as page templates or post types. ACF makes it very easy to toss things in and change them after the fact, almost to a fault, allowing developers to make quick but poor decisions.

Two-Way Relationships

The next bit to cover is two-way relationships and in this case the Posts 2 Posts covers this nicely. The main feature of Posts 2 Posts is the p2p_register_connection_type function that it opens up and the p2p_init action that it registers. The register function is used once for each Posts 2 Posts relationship and should be called from within a function hooked into p2p_init. Much like with custom post types, I would recommend creating a separate script to house all of the Posts 2 Posts relationships. Also, for simplicity’s sakes, unless your relationships have a very sound case for a very specific name or naming convention, I would strongly recommend naming the relationships after the two post types there are relating and to order those two post types alphabetically. For example, creating a relationship between the two post types event and service I would go with event_to_service.

Templating with Smarty

If you’ve had any experience with templating engines and PHP you’ve likely heard of or encountered Smarty. Fortunately, a small group of devs have made Smarty available within your WordPress theme (and plugins, but that’s a whole other discussion) with the Smarty For WordPress plugin. The Smarty for WordPress plugin works pretty much as you would expect with any experience with Smarty. The plugin likes to use your theme directory as its root, meaning you’ll need, at the very least, a templates directory to house all of your .tpl files and a templates_c directory for compiled/cached .php files generated by Smarty. Note that the templates_c directory needs to be writeable by your web server user. If you’re new to Smarty in general check their website to get started.

I’ve probably been using Smarty with WordPress for 3 to 4 years, and it has likely saved me in the hundreds of hours of both production time and later bug fix time. If you’re not used to templating engines, no matter what language you’re working in, you should likely change that.

Again, I’ll offer some tips on Smarty file layouts, I’ll save the bulk of that for another post, but for now I would recommend looking at your PHP template files as WordPress wants them to exist, and try to mirror those within your Smarty templates. I think this will call for a follow up post, getting deeper into some good Smarty practices in WordPress.

Apr 15, 2016