Wow that’s a mouthful of a title. I want to outline my WordPress development process when I’m doing client work. I see some freelancers doing odd stuff sometimes that makes me really atch my head. Like doing dev on a client server or editing locally but uploading every change. Check the 25PC services and tools.
That’s just crazy but whatever floats your boat.
Some notes before we get started: This process has been meal pieced together from working with or seeing what other developers do. I have my own unique way of doing certain things but most of this may look pretty normal. I’ll talk about UI Design, UX, User Testing, and any other phases in another perhaps more thorough post. This is more of just an overview for phases, approvals, or whatever you might consider a milestone.
Let’s assume we are doing a PSD to WordPress theme… contract is signed, deposit received, final PSDs in hand.
You can’t be anymore ready than right now, because you should have already done an overview of any technical requirements for markup or special WordPress functionality while you were quoting… right? ;)
Step 1: Setup Your Environment
A. The first thing I do is get all my files ready. My working directory looks something like this:
/project-name/
- /ui-assets/ (PSDs, wireframes, any stock, etc)
- /static/ (this contains my Front-End Starter)
- /WordPress/ (wp-content and DB… eventually)
- /docs/ (contract, quote, build notes, training docs, etc)
B. Create any local environments, github repos, etc.
C. Setup the client staging site on my server. Clients get a subdomain (projectname.mydevbox.com) that is protected by htaccess/htpasswd.
Step 2: Screencast & Final PSD Approval
Get those PSDs open and hit record in ScreenFlow! Walk through the layouts header to footer talking about how you’ll handle each element, especially if there are some tricky spots or you expect some kind of css or jquery animation to take place. Pull up an example to confirm thats what they want.
No responsive views? No problem. You can always put together some real basic wireframes with a site like Wireframe.cc and send those over with your screencast.
Talking through how you’ll build something also usually prompts questions you didn’t think of.
Pro tip: Don’t be a slouch. Use a legit mic like a Yeti and upload to Vimeo in HD.
Step 3: Markup
Here is where I might separate myself from some of the pack because I don’t use a starter or base theme. Custom design gets custom development.. but to each their own.
Load up your blank slate and get slicing. Once you’re done all your HTML/CSS upload it to projectname.myprivatedevbox.com/static/ and send it over to your client for any revisions.
This is the last stop to make any large changes to markup. Make sure they know that and once its #donedone you might even send an approval doc to be signed saying everything is kosher.
At this point I will zip the static pieces and send those over as a deliverable if requested. Most of my projects are 50% payments, so In my opinion we just hit the half way mark and you get a fancy zip file for your money.
Step 4: WordPress
Time to start building our WordPress theme. In my opinion there is no best way to build or organize a theme. It really depends on the project and its requirements.
There are a few different schools of thought on this so you may want to see these posts, but more than likely you already have a preferred way you do things.
- Andy Stratton Interview (Code Poet)
- Functions.php vs Plugin (Tom McFarlin)
- Creating a Site-Specific Snippets Plugin (Otto, man!)
- Functionality: Plugins vs Themes (Pippin Williamson)
At this point we might get into paid plugins or tools. If its used specifically for this client and not your developer license than they need to buy it. I don’t want your license being in my name. Occasionally I will bill clients for plugins and do the purchase for them but I prefer not to. The client should own everything they pay for.
Pro tip: Load up WordPress specific sample content showing all the design elements like headings, block quotes, img floats, captions, etc. and make sure they are styled to match!
Step 5: More Screencasts or Docs
As your client is going over the WordPress theme (issue them a user on the staging server install, duh) it’s time to start thinking about any custom functionality you built. If you didn’t I recommend WP101 for training if they need it.
But lets assume you’re just doing overflow for an agency. I hate writing docs but sometimes its a requirement. When it’s not though I prefer to still walk the client through how to use any of that custom stuff with a screencast.
Step 6: Final Deliverables
Send over a final sign-off document for the theme along with that final invoice. :) Convert pdf to word and use a great PDF converter support, exporting original PDFs into common file formats.
Once I get final payment I send them the final deliverables:
- Zip of working directory
- Zip snapshot of staging
Final thoughts:
This was rough and slapped together. I promise its a bit more refined than this but ultimately you need to find what works for you. My finite details aren’t going to work for you. Any little pieces or steps I didn’t include in this are too specific. Just like theme building or the way you write html/css (if you even do?) there is no “right way” to do anything, only suggestions of what’s working for someone else.
Different clients also get different processes or milestones. Some clients are super hands off, so they don’t get the approval doc treatment or maybe they get github access from the kickoff.
Feel free to voice any suggestions, praise, or hate below.
I do use a starter theme that’s really minimal but it already has Sass and Bourbon and Neat setup, something I’d have to do every time. It also has a stock comment markup that I find easy to work with.
Do you not find you end up repeating many of the same base setup things when you build a theme?
Sometimes, but not often enough for me to invest in a framework or starter beyond html/css one. I only see it saving me time with little stuff like making sure I don’t forget body_class or something.
I like my themes to be as lean as possible. Most of the sites I do are sometimes really detailed design work so having ready to go markup almost never saves me time except in instances like comments and search result pages. Areas I generally don’t get PSDs for basically. I see the use there for sure and have snippets saved but in a daily driver starter theme I would just end up pulling it out. Not that many sites I do even have blog layouts.
As for the chunk of the theme like functions I use a singleton class template I have ready to go with some base stuff in it to enqueue css, supports
So in a way I do have some base stuff, just not a full on theme with markup. More so a few templates and code snippets I regularly re-use.
I do think next year I’m going to (possibly) stop using Bootstrap in my front-end starter. I sometimes have issues where I try to fit Bootstrap into a PSD that wasn’t designed for a grid and its a mess. Plus starting from the ground up the markup is so much lighter. Probably just use H5BP as a starter and work from there, no grids or pre-written styles beyond some really base stuff, clearfixes, print styles, etc.
Part of it is probably also because I’m so far from a power user its crazy. I don’t even know what Neat or Bourbon is, other than thats how it’s supposed to be served. :p
I do need to get on the stick with SASS though.
Can you elaborate on “or editing locally but uploading every change or new file”. Most of my clients are SMB and on a shared hosting where git may not be available. I will create a local copy and make changes, test plugins, etc then upload those changes via ftp. If needed there is a staging server in the middle for the client to check out what’s been done but ultimately it get’s moved to the production site.
Thanks for the post!
Landon
Mostly just me being facetious. I meant like viewing your changes on the server, rather than running something like MAMP and coding out a theme then pushing to staging. More development practice rather than client side process, I was just trying to think of something random I hear devs doing sometimes. hah. hope you liked the post!
Yes, enjoyed it.
I am trying to workout better practices myself as a 1 person shop. I use MAMP and work locally but do SFTP it up eventually. Working on a good process that would incorporate GIT but I run into hurdles (quite possibly more created by me than anything else).
Thanks!
Great post Drew, thanks for sharing!
I’ve been using Underscores for a few of my last projects and found that it included just enough to be a good starting point without the bloat. To each his own though of course. :)
Thanks, glad you like it! I’ve used underscore in the past and its really well done. If I was going to use a starter and didn’t have time to roll my own, _s would be my choice!