Customer service is more than just solving problems and making people happy they decided to use your product. Support is a form of art. How you shape customer service is up to you. Like Thomas Kinkade and Pablo Picasso before him, success in art is defined by crafting an approach that best connects with your patrons. The most beautiful thing about art, though? When you start with a blank slate, you can take it in any direction you want. And the same goes for support.

Some say "good artists are born, not made." But the masters in the Louvre didn't emerge from the womb with paintbrush in hand. They developed interests and pursued those, learning from their experiences to better themselves — and more importantly, their processes — over time. If support really is an art…why treat it any differently? Shouldn't you be able to come to the table with little more than passion for the cause, and carve your own style that spreads throughout the community based on how well it speaks to them?

Running support with a non-technical background

Just over two years ago, I joined Modern Tribe to help handle support for Events Calendar PRO.

The premium plugin was still relatively new at the time. Shane — our CEO — and I did a daily divide-and-conquer on the CodeCanyon forum. The only strategy we had was "make sure to respond before people get pissed off."

That much I understood. But beyond that, things were hazy. Coming into this role I had no experience doing dedicated customer service, barely knew a thing about Events Calendar PRO, and had only a working knowledge of WordPress itself. I could find a line of code in a PHP file but wouldn't feel comfortable making changes myself. I could fake my way through a conversation on Javascript or CSS but would freeze up if asked to hack at core files.

And guess what? It didn't matter…and still doesn't.

If anything, a non-technical support lead can approach customer service without the constraints of a developer's mind. A non-technical support person views things as the customer does, and can convey community wants/needs to the dev team in plain English. They force devs to consider and plan for the fact that not all users are developers.

There is a line that you need to walk: give the devs too much control, and they may build what they want without considering the community. Let the customers drive the carriage, and you're sure to veer from the project's core scope. You're probably going to run over budget, too.

At Modern Tribe, we call the support lead a "community advocate." Remember that it's hard to advocate for the community if you can't put yourself in their shoes.

Since taking that first pass at CodeCanyon, we've grown. Support has become a five-person team and is likely to get bigger in 2013. Shane's removed himself from daily support entirely, and I've stepped back to a management role so I'm not as involved in the day-to-day exchanges either.

My technical skill is not much more advanced than it was two years ago. Likewise as I build the team, technical accomplishments are one of my lowest priorities. I want people who care and empathize; if that means they need to bring in dev help for the more complex support tickets, that's a tradeoff I'm more than willing to make.

Why all good support teams also do Quality Assurance (QA)

If a support team isn't at least partially involved in the QA process, they're doing it wrong. With proper testing instructions even the least technical support staff can effectively run quality assurance testing to verify that something works.

Consider five premium plugins, each with a dedicated support forum that one team member manages. This person effectively "owns" that forum: they address all threads, report feature requests and log bugs to the core dev team. As those come in, the dev team works off this feedback to produce the next release. When it’s time to verify that the new code accomplishes what the community wants to see, does it really make sense to have an isolated QA team verifying that? Ultimately, who'd be the most sensible person to conduct testing here? Answer: the support team member who initially reported the problem. They know the problem, have a rapport with the user and won't have to waste time researching how to replicate the issue. What better way to expose your staff to the code they'll be required to support in the near future?

This is why it's always surprising to hear from teams who handle QA differently. Normally they fall into one of these categories:

• QA exists independent from the support team.
• The devs who did the work do QA. (You'd better be damn confident in your dev team if this is the route you take!)
• There's no real formal QA process whatsoever.

The merits of each could be debated…except maybe the last. (That's just foolish.) But all three create silos — independent, isolated teams working among themselves, which makes for a fragmented experience for the end user. By exposing support to QA, and having support teams increasingly involved in pre-release testing so that everyone knows what’s shipping, we've been able to do a much better job of accurately communicating to users…and setting their expectations on the scope or timetable for a given fix.

As an added bonus, we've found as we get the team more actively involved in the entire project cycle, everyone becomes more excited and willing to share their ideas. The situational awareness such testing offers helps the support team to work more effectively with devs just as much as it helps in their customer encounters. This works well with co-located teams. But what happens with remote employees?

Avoiding the pitfalls of a remote, freeelance support team

Whether QA is a factor or not, support momentum becomes more complex when everyone works remotely. Consider the fact that the whole team is part time and everyone freelances — meaning they've got other clients, too — and things can get messy, quickly. We've only got so much overlapping time in a given day and so we have a strategy for handling support.

No system — no matter how awesome — is going to keep a bad team from failing. If you've got support staff who are genuinely disinterested, view this as "just a job" or who don't share the customer's sense of urgency, then you've got bigger problems.

As a general rule of thumb: if a support member doesn't approach every new support exchange with, "How would I feel if I were in this person's situation?" then they probably aren’t well-suited for a remote support position. The amount of uncertainty — the sleepless nights you'll have wondering how much babysitting this person requires to get the job done — you don't want that. As with anything freelance, you want self-starters: good people who you can count on to get things done. And you'll be able to tell pretty quickly which side of that coin they fall on.

You will find good people — they're out there. Here are few things I've found effective at maintaining momentum with my distributed team:

• A shared commitment to 24-hour response times. This is pretty standard, and I question the dedication of any team who doesn't guarantee customers a response of some kind within 24 hours of the original post. We openly publicize this 24-hour window. It forces the team to stay accountable, because they know there is no gray area: if your forum has threads outside that timeframe, you've failed and so have our systems. And it's going to warrant a discussion you'd probably rather not have.
• Twice-weekly scrums. We meet for 30 minutes, twice a week, to review the support obstacles we're facing. Everyone brings up exactly what stands in their way and we figure out how to work through it on the spot. Everyone normally comes away with one to two action items outside of their regular support duties, to report back on at the next scrum.
• An active Skype chatroom. We've got our broader "Products" chat with the whole crew, but we also started a support-only chat a few months back. What a change this has made! It's like a never-ending scrum meeting where we can ask each other questions and pass off threads or support emails to someone better qualified. Plus, there's just enough goofiness and off-kilter banter that it feels as close to a watercooler as you're going to find in the digital world.

Despite the fact that I have never met three of the four support members on my team, we've developed working systems that are as effective as any established by comparable groups working in physical offices.

Turn support into a flexible creature

Different systems are going to work for different teams, and that's OK. This piece is meant to be an overview of what worked for Modern Tribe in case it might work for you too…and you're welcome to take a page from our book if it does.

But if I could leave support teams out there with one bit of advice, it's to try new things. Buck conventional wisdom. Go with your gut and accept that your idea might not work.

What I touched on here and — for that matter — virtually every aspect of Modern Tribe's support system does not come from a book or from reading articles like this one. It comes from trial and error: seeing what works, what doesn't and adjusting to make sure it doesn't happen again. If you're willing to do the same, you'll learn a lot.

Image based on Billetes y sombreros by Germán Póo-Caamaño, CC-BY-2.0.

Parent And Child Themes Bundle Up

The Twenty Somethings — Twenty Ten, Twenty Eleven, and Twenty Twelve — are all perfect examples of themes created to function as standalone default WordPress themes and provide graceful support for child theming.

Out of its box, Twenty Twelve delivers a mobile-first design that accommodates clean typography, styling for multiple post formats, and CMS-ready page templates. At the same time, it’s completely customizable by way of child theming, or theme inheritance.

Parent themes pass on all their traits to their children, and when coded intelligently they allow their children to modify, add, or remove parent functionality entirely. This means taking advantage of core WordPress action and filter hooks to set theme defaults, appropriately outputting scripts and styles to page headers, and softly modifying fallback arguments for template tags.

When custom, non-hooked functions are used in good parent themes they are made pluggable; and, in general, parent theme stylesheets do not aggressively rely on ID selectors. In short, ideal parent themes are by themselves just right on the front-end and fully moddable on the back-end.

The maximum benefit of the parent-child approach is that child themes are relatively simple to create: a style.css file housed in its own folder is all that’s required. This means that WordPress developers who actively offer theme support are able to provide straightforward customization guidance to DIY users. The learning curve for rapidly creating child themes is gentle.

One downside of relying on the parent-child theme model is that any post-launch changes made to a parent will directly affect a child theme — sometimes with negative results. Because child themes take on all the code of their parents unless specific overrides are in place, even the most seemingly innocuous improvements to a parent theme can have far-reaching effects to its child themes.

If, for example, a parent theme author decides to modify internationalized strings, change from an ID-based styling system to a class-based styling system, or change a hook on which a custom function fires, she should carefully consider the fact that child themers may need to update their translations, rewrite their child stylesheets, and update their custom, hooked functions.

Theme Frameworks By Developers, For Developers

In a previous life I developed commercial WordPress themes for an outfit named Graph Paper Press. Its mission was — and still remains — to create sleek, minimalist themes for photographers and other creative people.

With every new theme we developed, we kept running into the same questions: How do we speed up development time and cut down on code repetition? How do we ensure maximum control when it comes to customizing an out-of-the-box theme without breaking future upgrades? And how do we manage all of the custom functions that we’re developing and use in every new theme that we ship out? For a time, a theme framework was the answer we came up with.

At their most complex, theme frameworks act as code libraries that aid in developing highly functional child themes. Theme frameworks are advanced incarnations of the parent-child theme approach and, when acting alone as parent themes, look like slightly baren fields waiting to for us to sow the seeds of our next best theme. Frameworks and their children feel codependent.

The reason theme frameworks are so fantastic for developers is that they allow an unparalleled level of fine-grained control over all aspects of a theme’s functionality and design. Frameworks offer custom actions and filters, custom callbacks for core-supported hooks, and blurred lines between plugin and theme territory. “I can make this theme do anything,” is what developers who make frameworks say.

In the WordPress.org self-hosted side of the theme landscape, theme frameworks are a viable approach for commercial theme developers who have little-to-no control over a customer’s hosting environment.

Where theme frameworks sometimes fail is that they are — for the average WordPress user — impossible to either understand or easily modify. Whereas with a bundled theme such as Twenty Twelve the process of overriding a template file or function is fairly straightforward, doing the same with a theme framework can be anything but.

The theme framework learning curve is steep, so much so that the most popular theme frameworks in the commercial market today have customization economies created around them for user support. Understandably, users who are forced to not only purchase a theme but also simple customization services often share their frustration with this development approach.

One more point to consider when developing with theme frameworks is the possibility of code bloat. Because they act as libraries, theme frameworks must include every function that will ever be called in a child theme. Maintenance and upkeep aside, keeping track of all the custom functions and custom hooks created by a theme framework is important. So too is good code organization in a framework. You may decide that this is too much overhead for a small project.

Theme frameworks absolutely have their rightful place in the WordPress ecosystem — they make life easier for developers but can create problems for the DIY user. Well-supported theme frameworks feel these effects much less than those that are left to rot on the vine.

Starter Themes A Wrangler’s Playground

At Automattic we — the WordPress.com Theme Team — face the challenge of finding, developing, and launching high-quality WordPress themes for millions of users.

We tackle this primarily by three methods: exploring WordPress.org Extend for stunning, fully GPL-compatible themes; partnering with premium WordPress theme shops who code well and provide superior support; and by crafting our own in-house themes.

For Automattic-developed themes we rely on the starter theme _s, also known as Underscores. A starter theme is, as indicated by its nomenclature, used as a project head start.

At its essence Underscores is a toolbox — in fact one of its predecessors is named Toolbox — that contains just enough PHP, HTML, and JavaScript to rapidly get a new theme off of the ground. It’s the 80% of a theme that results from 20% of up-front effort.

A close inspection of Underscores‘ stylesheet reveals resets and sensible typography, asset alignment rules for WordPress-uploaded media, and proper multi-level primary navigation styling. In addition, rules for screen reader text, post navigation links, and multi-author blogs are also present. “Just enough but not too much,” is the mantra of a starter theme’s stylesheet, where the primary goal of any code added is to avoid repetitive future work.

Lean, well-commented, modern template files are a hallmark of Underscores, as well as example code for oft-used theme features such as custom headers and theme customizer integration. And because the code that’s used is always the starting point of every new theme on WordPress.com, it’s well-vetted for security and WordPress best practices.

An important distinction between parent themes and starter themes is in how they are developed. Whereas every change to a parent theme brings with it the potential of adversely affecting all child themes that rely on it, with starter themes there is no concern.

Starter themes are not parent themes, and should never be used as such. They are meant to be constantly iterated upon and in flux. They exist to make launches happen faster and make code quality better with each new theme launch. The Underscores of today is markedly different than the initial version that launched, which means that the practice of always making it better is succeeding.

Without a doubt the largest speed bump to using starter themes is that in this development model there is no bug fix and enhancement inheritance that’s enjoyed by the parent-child theme workflow. If a critical bug fix occurs on the canonical version of _s, then manual updates to every theme spun off of all prior versions must take place.

With time, however, this negative aspect of starter themes is greatly diminished. Every time Underscores is used to begin a new project, a fresh set of eyes audits its code pre-launch, meaning that gradually the process of large-scale manual bug fixes to old starter theme code fades away.

Building From Scratch Freelancers And Agencies Unite

The major assumption I’ve made up until this point is that you’re developing a WordPress theme to release it publicly. When we drop these approaches in favor of one more tailored for client work, starting from scratch emerges as another clear option.

When I write “starting from scratch,” what I really mean is ignoring, for the most part, commonly held WordPress theme guidelines and doing only what is absolutely needed for integrating WordPress into a project.

A theme that contains only a single stylesheet and a few template files would not be accepted on WordPress.org or WordPress.com, but that doesn’t mean it wouldn’t be completely appropriate for a one-off gig or WordPress-powered microsite. After all, all that’s needed for a theme to properly operate is a stylesheet and an index file.

Similarly, large-scale projects that are a mashup of theme, plugin, and web application are not well-accounted for by the approaches I’ve covered above. For these projects the best way forward will likely be dictated by budget, time, and administrative constraints. For all three limits, using a starter theme will at the very least act as a sanity buffer.

Go Forth And Theme

So: parent-child themes, theme frameworks, starter themes, or building your theme from scratch? Now that you know a little bit more about the pros and cons of each, you’ll be able to make better decisions on personal and client projects alike.

Each approach exists as a scenario-specific response, and I’m confident that in the future more interesting problems and solutions will emerge as WordPress themes evolve. Good luck with whichever approach you choose, and may your adventures in wrangling always be fantastic.

Based on “IMG_0270.jpg” by Hello Turkey Toe, CC-BY-2.0.

The answer is yes — only if you want to get paid.

Ok. I get it. I should have contracts in place with all my clients…does that mean I need a lawyer too?

Ideally, you should have a lawyer who can draft a formal agreement that fits your needs.  If you don’t have access to a lawyer to help you, it’s not hard to write up a simple agreement, on your own, that accurately reflects your business arrangement.  Doing this is much better than operating with no agreement in place at all.

Agreements 101

Here are a few basic points that a simple contract for web services should cover. Your lawyer (if you have one) will be able to provide a lot more detail on what your agreement should look like, and the terms you should have with your clients (these vary a lot depending on the type of client you have and the work you’re doing). Here are some questions to consider as you draft your agreement:

• Who are the parties? List each party.
• Are the web services being done by you, as an individual, or through your LLC or corporation? Be specific!
• Is the client an individual (with assets) or an LLC or corporation? Be specific!
• If the client is a corporation or LLC, are you comfortable that they have the assets to pay your fees?
• What are the obligations of each party? List each party’s obligations. Be sure to include the payment schedule.

Clarity above all else — put it in writing

You, as a service provider, should be crystal clear about what you will and will not do under your agreement. Any vagueness can lead to disagreements about whether you’ve fully completed your obligations (and therefore whether or not you are entitled to be paid.) The client, should, at a minimum, be obligated to pay you on the schedule you agree to. Also, think about what you need from the client to do the work that they’re expecting, and then make sure that your agreement says that the client will provide you with whatever you need to do this work in a timely manner. If it’s access to their servers, or something as simple as a meeting with their CTO for one hour per week to answer questions, it’s a great idea to specify these requirements up front to avoid issues later. Here are some additional considerations as you draft your agreement:

• What is the timeline?
• When do you have to deliver your deliverables?
• When are payments due?
• Does the client have the right to accept/reject deliverables? How many rounds of revision are included?

If the client has the right to accept or reject the deliverables, outline a strict timeline: if the client hasn’t rejected a deliverable (clearly, in writing) after a defined time period, you should be entitled to the applicable payment for that deliverable.

Payment options

No matter which payment structure you use, the contract should be clear about when payment is due, when you must invoice the client, and whether expenses are to be pre-approved or reimbursed by the client.

On timing — it’s a good idea to require some portion of the payment up front. If a client is unwilling to pay something toward the project once you’ve defined the scope, you may have problems collecting the amount due at the end of your project.

The time/materials relationship and you

A common form of consulting relationship is what’s called a “time/materials” relationship: The agreement for this type of arrangement will specify a deliverable and say that you’ll bill the client at an hourly rate, plus expenses.  Many times under these agreements, though, clients will request a cap on your total fees.  If they do, it’s important to be clear on the fee cap, given the scope of the work. If you think you can’t deliver the requirements and meet the fee cap, it’s a good idea to either renegotiate or understand that you are agreeing to eat the overage when you sign an agreement with a fee cap.

Milestone-based payments are also very common. For these type of arrangements, if possible, make sure that the milestones you agree to meet are under YOUR control and not subject to the client’s changing opinions or material delivery.

Many clients like to pay upon acceptance of the work. In other words, if they don’t like the end product, then no soup for you! If you’re going to allow a client the right to accept or reject the work, it’s a good idea to specify a small portion of the payment subject to acceptance. This way you’ll get something for your efforts, no matter what.

Scope creep

The biggest area for potential conflict in a contract is “scope creep.” Your contract should define the scope of what you will do for the initial set of agreed-upon payments. If you want to change any of these expectations, create an amendment to the contract where both parties agree to the new deal by signing off on it.

A very common scenario is a client that changes their mind about “just this one little thing” and then again asks for changes on “just this other little thing.” You, wishing to do a good job, go ahead and make the changes, even though this extra work isn’t in the contract. This isn’t a problem until later, when a disagreement arises about whether you’ve completed the work. Now, the definition of the scope of your “work” is strung out across conversations and emails where “little things” came up and, unfortunately, individuals have very different memories of what changes were agreed on.

The lesson is: if you are going to change project scope, timing, or cost, get it in writing.

Having a written agreement is very important. Get the details in writing and try to be as diligent as you can in updating the written agreement to match up to the work that the client wants done. Your agreement does not need to be a fancy, air-tight legal contract — anything you put down on paper to set and maintain expectations is better than nothing. Going through the process of writing things down may be a bit more effort on the front end, but making this a practice for your business will save you a lot of time, effort (and probably money too) in the long run.

Thanks to Tennille Christensen for help and insight that shaped this piece.

Image based on “World war 2 parachute at Old Sarum living history weekend” by fribbleblib, CC-BY-2.0

1. Change your permalink structure

Search engines can’t display your content on the right Search Engine Results Pages (SERPs) if they can’t determine what your posts and pages are about. One thing that can hinder search engine crawlers from understanding the subject of your content is badly formatted post/page slugs. The default WordPress permalink structure (the format used for post and page URLs), which looks something like yourdomain.com/?p=17, is not always optimal for SEO.

Changing your permalinks to include keywords about your post helps Google, Bing, and Yahoo to better determine what your posts and pages are about, which means that you can compete for rankings for the relevant keywords. The most common permalink structure is /%year%/%month%/%day%/%postname%/. Yoast has a great guide on changing WordPress permalinks that I’d recommend reading.

2. Use keyword-rich post slugs

Semi-related to permalink structure, keyword-rich post slugs (or URLS) are another key to getting ranked. Don’t be afraid to use moderately long post slugs. Using slugs that contain your post’s title include more keywords, thus improving crawlers’ ability to comprehend the subject of your content. That said, don’t go overboard. Here are three examples of post slugs: one too short, one too long, and one that’s just right.

• Too short: birdbaths.com/make-bird-bath.
• Too long: birdbaths.com/build-bird-bath-yard-ornament-diy-weekend-warriors.
• Just right: birdbaths.com/build-a-heated-bird-bath.

Here’s a good article by Dig WP on Optimizing WordPress Permalinks.

3. Optimize your title tags

Everyone hates the guy who forgets to change his page title from “Untitled Document” to something more relevant. With WordPress, you probably won’t end up with something that ghastly – you’ll likely end up with the defaults for the theme you’re using. While this is not always a bad thing, it’s better to have a little more control over how your titles display.

This is important because title tags, rather than simply filling up space at the top of the browser window, are the first thing that search engine users will see. Joost de Valk, WordPress SEO expert, says that page titles are “one of the single most important factors for ranking in the search results.” Here’s the rest of Joost’s article about SEO titles.

Good title tags spring from good post titles. An example of a good title tag would be: Top 10 Ways to Become Better at Tennis | Tennis for Beginners

4. Configure meta descriptions for posts and pages

Don’t neglect your meta descriptions. A custom-written description is much more appealing than the first sentence of your post. It doesn’t take that much more time to write a nice description for each post. Sometimes less is more when it comes to descriptions, so you can be concise while including your keywords. Make it interesting. Ask yourself, “would I click on this?”

WordPress doesn’t allow you to edit meta descriptions out of the box, so you’ll need an SEO plugin (as discussed below).

5. Use an XML sitemap plugin

Submitting an XML sitemap to search engines is a great way to ensure that your entire site gets indexed. Unless you enjoy writing XML from scratch, the easiest way to submit a sitemap is to use an XML sitemap plugin like Google SEO Sitemap. Very easy to use, this plugin automatically updates the sitemap each time you create a new page or post and re-submits it to the major search engines.

6. Use an SEO plugin like All in One SEO Pack

All in One SEO is, by far, the most widely used SEO plugin for WordPress. Install it. It will save you tons of time throughout the SEO process. It allows you to set your page title format, adds a meta description to your post editor, and lots of other great features.

7. Set up Google Authorship so that your G+ profile picture shows next to your posts

Linking your Google+ account to your blog is a great way to make your articles stand out against other results. There’s no reason not to set this up. Brian Gardner has an article you can use for setting up Google authorship with WordPress.

8. Noindex irrelevant archive pages

There are a number of reasons why you should do this. For one, you can get penalized by Google because their crawlers think you have duplicate content. Second, since the title of date-based article has nothing to do with the posts they’re linking to, it can actually hurt your rankings for keywords. Rae Hoffman-Dolan has an article titled How to Optimize Your WordPress Archves for SEO, which explains in detail why this is a good idea. The article is written for the Thesis theme, but 99% of the info is relevant for all themes. She also suggests choosing either category-based or tag-based archives, and noindexing the one you’re not using.

Micah Cooksey is a 19 year-old designer and entrepreneur living and working in greater Portland, Oregon.  He currently works for Treehouse, a startup dedicated to providing quality, affordable tech. education to anyone who wants it.  Micah started using WordPress when he was 14, and still thinks it’s one of the best ways to power a website.  When he’s not working, he enjoys running, writing, and woodworking, among other things.

Image credit: “Barcelona, Gaudi, Sagrada Familia, Door, Typography” by Melissa Delzio, CC-BY-2.0

Theme Sense is not about memorizing code

Let’s think about mathematics and “number sense” for a second. If you teach a kid just to memorize arithmetic facts on flashcards, without explaining why the answers are what they are, that kid may struggle when they encounter a fact they haven’t memorized. For example, demonstrating 5+2 = 7 using blocks helps the kid “see” how numbers work. They can then use this knowledge to help solve any problem they run into in the future, even if they haven’t memorized the answer.

Theme Sense works the same way. It’s important to focus on the larger picture of what you’re trying to achieve, instead of memorizing specific bits of code.

How do I develop my Theme Sense?

Theme Sense is about being aware of what you’re doing, and making conscious, informed decisions along the way. For example, if I asked you to design a car for me, you’d instantly know which parts to include in your design—engine, frame, tires, windows, exhaust pipe, and so on. You might not know how every single part works, but you’d be able to explain why you need them in the design, and you’d be sure to verify the quality of the parts—which is super important for safety.

Use a similar approach when you tackle your next theme project. Ask yourself:

• Which files do I need to include in my theme?
• What role does each of these files play?
• Why am I about to paste this bit of code into my theme?
• Where did this bit of code come from, and who wrote it?
• What purpose does this code bit serve? Is it up to date? Is it safe?

You don’t have to understand the mechanics behind every single line of PHP, because it may change two, three, or four release cycles down the road. What’s important is that, like with cars, you’re able to demonstrate a macro understanding of what your theme is doing under the hood.

That said, here are some specific things you can do to develop that macro understanding and to keep your Theme Sense sharp.

Know “What’s New” with WordPress

WordPress code is all over the web. It’s even found its way offline, and into books and magazines. When you gaze at stars in the night sky, you’re seeing them as they existed millions of years ago. Likewise, when you examine a WordPress code sample, that sample is a snapshot of WordPress as it existed at the time of writing, and not necessarily WordPress as it exists now.

Awareness of the latest WordPress versions and major new features will help you evaluate the timeliness of WordPress tutorials, books, and plugins. To keep up with WordPress releases, subscribe to the WordPress News blog.

Get in the habit of checking dates

The first thing you should check before reading any tutorial or book is the date that it was published. Remember how important it is to know “what’s new” with WordPress? That will help you evaluate which parts of a tutorial are still relevant, and which code is still current enough to use in your theme. As you may already know, it’s dangerous to use obsolete code in a theme because it may have known vulnerabilities that hackers can exploit. Relevancy is not an all-or-nothing deal, though, and code doesn’t come with expiration dates. You must determine relevancy on a case-by-case basis. The good news is, there are several resources you can turn to.

If you do use outdated code in a theme, it’s not the end of the world. There are plugins, such as Developer and Theme-Check, that will help you optimize your WordPress theme development environment and scan your theme’s code for currency, respectively.

In addition to the developer plugins, it’s great to get into the habit of adopting the best security practices listed in the Theme Security and Privacy Guidelines on the WordPress Codex’s Theme Review page. Scan the list and make note of any that refer to features you’re using in your theme. For example, items that refer to data validation and sanitation are necessary to protect your site from Cross-Site-Scripting (XSS) attacks.

The principle behind the second item on the Security and Privacy list is especially pertinent when we’re talking about code relevance and timeliness:

Themes are required to implement Theme Options and Theme Settings pages deliberately, rather than relying on copy-and-paste scripts from website tutorials.

Copy-and-paste scripts may become obsolete very quickly. This applies not only to theme options code, but code from any tutorial. Be aware of the importance of timeliness and keeping your theme as secure as possible.

Understand the essential elements of WordPress themes

Most websites, whether they run WordPress or not, have the same general sections: a header area, a main content area, a sidebar, and a footer. It might be helpful to think of these sections as blocks (or car parts, your choice). You’ll use some blocks, such as the header, footer, content, and sidebar, in every theme you develop. You just might stick them together differently depending on the purpose your theme is trying to serve. With WordPress themes, template files such as header.php, index.php, sidebar.php, and footer.php are your “blocks.” Therefore, the theme is the completed structure that you build with these blocks.

Awareness of these essential elements will go a long way to helping you to develop theme sense. For a quick primer on the parts of a WordPress theme, check out the The Theme Development page on the WordPress Codex.

Know where to find the latest coding examples and standards

The WordPress.org Codex is a great starting point to research WordPress functions and template tags that you find in tutorials. If a function is deprecated, The Codex page for that function will note it and point you to the most current alternative. You can also find a list of all deprecated functions in the Codex. Additionally, check out the Log Deprecated Notices plugin, which logs deprecated functions, function arguments, and files whenever they occur in themes, plugins, and WordPress Core.

The WordPress Theme Review Team has a set of guidelines that all themes must meet to be approved for the official WordPress.org free themes directory. Evaluating your code against these standards can help you to stay abreast of best practices and standards.

Finally, when in doubt about something, there are places you can go to ask questions, such as the Themes and Templates section on the WordPress.org Support forums. If you prefer live chat, there’s the general #wordpress support channel on the irc.freenode.net network.

This is not to say that you should never break out of the mold when building themes. Rather, the idea is that it’s smart to be aware of the decisions you’re making for each theme you develop and why you are making these decisions.

Take-aways

The points to take away from this article are:

• Know what major new features were introduced in the latest version of WordPress.
• Pay attention to the dates on all WordPress-related tutorials. Use those, combined with your knowledge of the newest WordPress features to evaluate the relevancy of any given tutorial.
• Understand that code changes regularly, but the basic building blocks of a theme stays generally the same.
• Be aware of current best practices and standards. This can also come in handy when evaluating a tutorial’s relevancy.
• Understand why you are making the decisions you’re making for your theme—for example, what purpose does each template file in your theme serve? If you’re about to paste a large block of code into your theme that you dug up from Google, what purpose is that code serving? Is the code relevant? Up to date? Secure? You don’t have to memorize every line of PHP. What’s important is that you’re able to comprehend your theme on a macro level.

Image credits:

• “IKEA Espressivo Bulb Replacement Instructions” by Richard Eriksson, (CC-BY 2.0)
• “Please Don’t Eat Me” by Nikki.L, (CC-BY 2.0)
• “DOS Angry Birds” by Patrick Hoesly, (CC-BY 2.0)