My WordPress workflow.

How I Rock, and for the most part Roll

Like anything there is the hard way, and then there is the right way. 

I don’t know about you, But I have a lot of other things that I would rather be doing.

WordPress is great in what it does. It can also be very frustrating as you peal back those legacy layers and expose the underlying Hooks and Queries that are at the heart of WordPress. Spending some time in the Codex, Digging through the source code, Reading up on best practices, and even having a better understanding of how PHP definitely aid in the speediness of your projects. 

With that said, I would like to share some of my process with you.

 

1) The Customer

Before you even think about starting the project, Establish all expectations. Clarify communication channels and response times. I work in the evenings and as such take longer replying to emails first thing in the morning.

Like expectations, the site Architecture, and Interface need to be nailed down. No one likes a broken record, and no one likes to redo work.

 

2) Server Environment

Local

I work locally using MAMP with php 5.3 over a local site like project.dev and will use Git ( public facing ) or BitBucket ( Private ).

Remote ( Customer )

I generally ask about hosting providers before I get started, its good to note that you can waste a lot of time screwing around with some ISP hosting, or some rinky dink operation. My Prefered hosts would be Digital Ocean, Dream Host, Media Temple, and anything with a cPane. And in that order.

I will recommend Dreamhost to customers who don’t have existing hosting and here is why.

  1. It is cheap, reasonably fast, and supports WordPress like a champ
  2. You can also get a referral by singing recommending new customers.

 I have used them for about 8 years and only recently moved off of their service..

 

3) Setting up WordPress

This is more basic stuff and harder to automate, although it is possible and I will get into that in a moment. For now these are the manual steps that get my production environment setup.

  1. Stub all pages and structures
  2. Build Navigations
  3. Define any custom taxonomies and post types ( Don’t worry about custom data yet )
  4. Figure out what if any plugins you will require

 

4) Front-end design

My projects all use some standard folder structures

  • Project Name
  • Project Name/_design
  • Project Name/assets
  • Project Name/assets/{ css/fonts,ico,img,js,less,source,vendor}
  • Project Name/lib
  • Project Name/templates

I configure Photoshop to generate image assets on the fly for me, This means that as you make changes or save your PSD, the supporting graphics will be dumped to a folder. Grunt will then watch for this, move and optimize the images to my /assets/img folder. I also have the option from this point to SFTP the images to the client server.

I will also use Grunt to monitor changes to assets/js/source concatenate/minify to assets/js/file.min.js from this point I will also watch for changes and SFTP if needed.

LiveReload is a great tool and I use it as much as I can while working on the Front-end code.

Compiling less and javascript is usually done with CodeKit locally, If I am working remotely then I opt for Grunt as I can sync the changed files to the server.

LESS is nothing new, but I do use a custom micro framework based off of Bootstrap but with a few differences to the grids naming convention. I have also remove all of the components. I work off of an OOP principal where you should extend a base class rather than overwriting one. I end up with a nice and flexible grid system. A supportive less structure that I can bring in other components with little effort.

Take a look at https://github.com/adampatterson/Dock

 

5) Development

Debugging

Debugging is where you can really make up time. Most of the sites I do these days don’t follow the standard WordPress mold.  Working locally I use Xdebug, not so much for integration into an IDE ( But this helps ) but to help view object data returned by WordPress. Without Xdebug you get a mish mash of unreadable text. Xdebug will also provide better errors and stack traces for you.

Avoid if possible enabling WordPress debugging, you will likely be beat in the face by pre-existing errors from other plugins. For the most part this has to do with PHP versions, some times its poor coding practice.

If Xdebug is something that you just can’t use then consider WordPress Debug Bar.

My starter template

Some other time savers include various helpers broken down into 

  • function.php
  • lib/init.php
  • lib/theme-helper.php
  • lib/theme-functions.php
  • lib/theme-required-plugins.php
  • lib/custom.php

I also use these functions to configure the admin side, cleanup the header. Customize the login page and so on.

As I mentioned before, it is also possible to create content on the theme activation. This could be the Usual contact, about, and blog pages, read more about it here.

Some other time savers include functions for including assets. 

  • j() // javascript
  • a() // asset
  • c() // css
  • i() // images

I go into more detail here about WordPress routing, but to me this is a civilized approach to the template hierarchyThe default way would be to create template for all of your pages by the end you have a messy root theme folder.

Some good starters worth looking at include Underscore and Roots. I don’t have any experience with Roots, but it does come as part of a development process using deployment methods and composer. Something to look at if you are so inclined.

Signup for my mailing list

Receive other rambings like this on design, code, and some times food.