Cowboy Coding To Professional Developer – WCKC 2015

WCKC2015_Speaker-150x150Notes and slides from my WordCamp Kansas City 2015 presentation ‘Cowboy Coding To Professional Developer’.

(these are my presentation notes straight out of Evernote… please ignore formatting and grammar issues)

The first half of the talk has general tips on being a better developer and the second half of the presentation is focused on a professional WordPress developer’s workflow and quick tips. The goal of the presentation is not to tell you how to develop – but to provide singular tips that will, individually, make you better. You don’t need to adopt them all at once. Use them as needed as each is generally independent from the next.

Don’t code live on your production server (yeeeee-haw). Use version control. Be nice, use standards, and avoid shiny object syndrome.

This presentation contains bite sized nuggets – suggestions where if you take one thing away from this talk you will be a better developer. You don’t have to do everything at once. Incremental improvements are easier to turn into habits. I’m not going to take to big of a deep dive but have added a ton of references in the presentation notes so you can explore on your own. Check those out at What is cowboy coding? cowyboy Cowboy coding is flying by the seat of your pants development – editing files live on a server just to see what happens. There’s nothing wrong with it – unless you are getting paid. It’s an essential part of learning a programming language, framework, library or platform. It’s a great place to start… but it’s also dangerous when you are dealing with other people’s systems, websites, and codebases.

A Better Developer

Being a better developer is rarely about learning syntax, patterns, and conventions. That’s the easy part. It’s how you work that matters It’s being pragmatic, conventional, efficient, and empathetic.

TL;DR Don’t code live on your production server. Use version control. Be nice, use standards, and avoid shiny object syndrome

Being A Better Developer

Be Pragmatic

      • Be practical and care about your craft
      • Don’t try to solve problems you don’t have
      • Don’t optimize early
      • Don’t over-abstract
      • if something works – it works. stop tweaking and move on
      • make quality a requirement

Be Empathetic

      • Someday, someone else is going to have to work on this code. Don’t make them think.
      • If you have to include a README with every project you work on so another dev can pick it up. Think about it first.

Learn source control from the start

      • preferably git
      • Source code control is a time machine for your work—you can go back
      • Source code lets you sanely work with other developers

Use Standard Conventions

      • If you are an empathetic developer you will be thinking about future developers when you are designing systems. There’s nothing worse than jumping into someone else’s code and have no idea how it works.
      • Following conventions helps alleviate the pain of adding another developer to the project. They don’t have to figure out ‘how you code’ and try to fit their styles into yours

Tools don’t matter. Tools are everything

It’s not about what tools you use – it’s about what tools you are productive with. Don’t force your tools on anyone else.

Be A Good Teammate

      • this goes back to being empathetic… think about the other developer when you are writing code
      • don’t arbitrarily add required tools and frameworks to a project if your team isn’t familiar

Avoid Shiny Objects

      • You’ll hear a lot of talks about awesome tools like Grunt/Gulp, Bower, Composer, NPM, SASS, LESS, and more. But do you REALLY need them? A professional developer will take a pragmatic approach to the tools she uses rather than what’s trendy.
      • Do you REALLY need to run gulp tasks to minify all the things for a website with one developer and 1,000 visitors?
      • The more tools you add the more complex your system and the harder the handoff (or the picking back up on your part in a year after you’ve switched to the latest toolset the cool kids are using)

Be Verbose

      • leave detailed comments in your code
      • leave detailed comments in your commits

Automate Things

      • the definition of insanity is repeating yourself
      • if you can automate something – do it….
      • but think before you automate

Code in Objects

      • learn and use object oriented coding standards
      • reduce code duplication
      • simpler, testable functions
      • can use singletons and inheritance
      • easier to share code due to readability and general understanding

Test Your Software

      • or your users will
      • unit tests, automated tests, continuous integration

Don’t Repeat Yourself

      • refactor often
      • abstract common functionality

Working With WordPress

The thing I like most yet despise most about WordPress are the infinite ways you can do something. These may not be the best ways or your ways… but anything is better than nothing.

Use A Local Dev Environment

      • first step in not being a cowboy is to get your own sandbox – a place you can develop and test on that’s easy to rollback (hello git)
      • Doesn’t matter what you use, just use something (ie tools don’t matter tools are everything).
      • Popular Solutions include MAMP Pro, Desktop Server, VVV
      • Get your favorite editor and your favorite terminal
      • Popular Git UI’s include Tower and Github
      • My setup is MAMP Pro, Atom, iTerm, Git bash
      • this is also a good time to mention … you may want to add a staging environment to the mix. There’s a good chance you’re local dev environment won’t mimic production. It’s fine 95% of the time but to really make sure you can setup a staging environment to deploy to that is a replica of your production environment. Y

Syncing Data

      • so you have a local development environment to work on a site that’s been live for a year… how do you know you are dealing with the same set of data
      • I recommend WP DB Migrate Pro
      • easy data migration
      • push / pull to synchronize data between environments
        • ie – pull from production to replicate the live site in your local environment OR sync data between dev / staging / and production.
      • tools exist so you never have to dive into SQL / PHPMYADMIN anymore

Deploy with sanity

      • Stop doing things manually
      • Use WP-DB-MIGRATE to move data
      • Use WP-Pusher to deploy updates from a Git repo (no FTP, yay!)
      • Use Git to pull/push on your server
      • Capistrano or Chef

Being A Better WordPress Developer

Easy tips to be a better WordPress developer. You don’t have to use all of these tips at once. But when combined they will increase your super powers. Pick and choose as you have problems or roadblocks and use them as a chance to improve your environment, workflow, or productivity.


  • When doing local development
  • It will write PHP errors to the screen
  • You don’t generally want to ship anything with errors :)

What should be in a Git repository?

  • Should I check the entire WP install into Git or just the themes / custom plugins individually? YES.
  • Depends on your situation and team
  • Never check in wp-config.php
  • you don’t want passwords in a repository
  • you don’t want to accidentally put WP_DEBUG in production
  • Pros of checking in the entire site
    • If you check in everything it’s easy for another developer to clone the entire project and start working
    • If you check in everything you can version updates of your entire site to stage WP core and dependent plugin updates
  • Cons of checking in the entire site
    • WordPress and plugins are version controlled elsewhere and it’s hard to stay up to date

Separate your concerns

  • Use plugins for functionality, Use themes for design
  • Don’t add functionality to your theme’s functions.php – instead create a functionality plugin
  • Even better – build small, maintainable plugins to manage your site
  • Allows much easier updates
  • Much less dependency
  • IE if you have a custom post type – make its configuration, implementation, and registration a singular plugin

Use WordPress Coding Standards

“Coding standards help avoid common coding errors, improve the readability of code, and simplify modification. They ensure that files within the project appear as if they were created by a single person.

Following the standards means anyone will be able to understand a section of code and modify it, if needed, without regard to when it was written or by whom.

If you are planning to contribute to WordPress core, you need to familiarize yourself with these standards, as any code you submit will need to comply with them”

Use Core Features

Theme Customizer, Settings API, Options API, Image Thumbnails, Menus, Widgets, Shortcodes and more make development easier

Enqueue ALL The Things

Make sure to use wp-enqueue when including scripts or stylesheets in any plugin or theme.

Use Template Parts

  • create reusable theme snippets
  • create reusable loops
  • reduce and reuse code

Validate, Sanitize, Escape

  • validating = checking user input
  • sanitizing = cleaning user input
  • escaping = securing user output

Transients Are Your Friend

  • simple caching means big performance gains
  • store data you expect to expire
  • example: custom query results, api responses, etc

Variable Scope

  • use namespaces and classes to scope your variables
  • don’t define unnecessary globals


  • a command line interface for WordPress
  • setup, install, and configure sites from your terminal
  • easily create scripts
  • automate and schedule db migrations

Manage Dependencies

  • you can use plugin_exists( ‘my-plugin’ )class_exists( ‘MyClass’ ), or function_exists( ‘my_awesome_function’ ) to ensure a dependent plugin is active
  • TGM Activation Plugin
    • require / recommend dependencies in your custom themes and plugins
  • Use Composer
  • good option if custom plugin / theme requires third party dependencies

My toolset

  • Editor:
  • Local Dev: MAMP Pro
  • Terminal: iTerm
  • Source Control: Git with Bitbucket
  • Data Migration / Sync: WP DB Migrate Pro
  • Deployment: WP Pusher, Git
  • Management: InfiniteWP

My workflow

  1. Grab a task (from Github, Trello, or Jira)
  2. Pull latest version of the project from git
  3. Pull latest version of data with WP DB Migrate Pro
  4. Code feature / bug fix
  5. Commit and push code to repo with verbose comments and link to ticket/issue
  6. Deploy with WP Pusher or Git

Link Dump

Better Developer

Learn Git In Your Browser – learn
Object-Oriented PHP for Beginners – read
The Pragmatic Programmer: From journeyman to master – read
70 tips for pragmatic software development – read


Installing a Local Server – read
How We Deploy WordPress Themes – read
A Series of Deployment Workflows  – read
WP DB Migrate Pro – download

WordPress Tips

WordPress Code Reference – read
WordPress Coding Standards – read
The Importance of Following The WordPress Coding Standards – read
Create A Functionality Plugin Instead Of Using functions.php – read
.gitignore for WordPress – read
Enqueuing things – read
Validate, Sanitize and Escape – read
WP Migrate DB Pro CLI Addon: Push/Pull – read
How I Would Solve Plugin Dependencies – read
TGM Plugin Activation – download
WordPress template part: a powerful tool – read
get_template_part() – read
WordPress Theme Customizer Resources – read
WordPress Plugin Boilerplate – fork
GenerateWP – use
WP Pusher – download


PHP Storm – download – download
Sublime Text – download
MAMP Pro – download
Desktop Server – download
VVV – download
iTerm – download


WordPress Single Page Template For Categories

If you are familiar with building WordPress themes you’ve likely caught onto the naming convention used for page templates. These conventions are things like ‘page-{slug}.php’, ‘single-{slug}.php’, and ‘category-{slug}.php’.

The conventions are very handy and I wanted something similar for posts in a category. This method is much cleaner than having conditional logic all over your ‘single.php’ file to do have different design elements or functionality for posts in different categories.

A simple one-liner to drop into your theme’s functions file does the trick…

Now, you can create ‘single-news.php’ for a post in the News category and ‘single-blog.php’ for a post in the Blog category and have completely different designs and layouts.

Style Disqus Comments in Twenty Fifteen Theme

I’ve recently moved several of my content based WordPress sites over to the Twenty Fifteen theme. It’s just so clean and neat … and focuses on content rather than features. Paired with Jetpack you can run a pretty awesome blog.

Anyway when I started applying this theme to my sites already integrated with the Disqus comment system I noticed the style was all off. A bit of Googling found me at Alex’s website reading about how I can apply some custom CSS to fix the issue. That’s awesome but not a simple feat for your average WordPress user and somewhat of an annoyance for someone that doesn’t want to install a Custom CSS plugin or create a child theme just to apply some custom CSS rules.

So … I turned it into a WordPress plugin to make it easy to fix for everyone. Hats off to Alex Dresko and ultimately Joshua Granick whose CSS I actually used  (he left a comment on Alex’s post – which runs on Disqus… how meta).


Twenty Fifteen Disqus Comments


Twenty Fifteen Disqus Style


Download on / Fork on Github

Zendesk Helpdesk Widget in WordPress Admin

When managing dozens of WordPress sites for dozens of different users, streamlining the support process using an excellent help desk system quickly becomes a priority.

If you are not familiar with Zendesk, it’s a help desk / ticketing system on steroids allowing you to manage support requests, setup response macros, manage a knowledge base, and more.

My Admin Zendesk Help Widget plugin (ya … bad name) utilizes Zendesk’s web widget which you can configure via a simple plugin settings page. Customizing the widget is easy in your Zendesk dashboard – you can change the colors, position of the Help button, and much more. Information about the current logged in user auto populates the fields and when a user submits a support requests it shows you what page the request was made from in the Zendesk ticket.

Installing, activating, and configuring the plugin can be done in 60 seconds. All you need is a Zendesk account and to know your subdomain (that will make sense if you have already signed up).

Download on WordPress Plugin Repository / Fork on Github