Whether you offer free or premium themes, testing should be a major part of your development process. By planning in advance, you can foster a development environment that deters some bugs by design and that helps you prevent others. The aim of this article is to share some of the tricks I use personally during and after development to achieve a bug-free product.

This article is split into three distinct sections:

1. Setting up,
2. Development phase,
3. Final testing.

This should give you a good overview of what you can do over the course of the development cycle. I invite everyone to chime in with their own tips in the comments. I’d be interested to hear your tips on testing WordPress themes!

Setting Up

Setting up your environment correctly can go a long way to preventing bugs and helping you to find them more easily. For me, it all starts with version control.

Setting Up WordPress

You could do about a million things when setting up WordPress to ensure you make as few mistakes as possible. I always do a number of things:

• Using a network (WordPress Multisite)
  While not much different, developing for a network installation does present some differences in methodology (especially with plugins). Because I use one network for the themes that I make, it is still useful, and I can make sure that the themes work properly on network installations as well.
• Custom table prefix
  Installing a custom table prefix helps in two ways. First, it ensures that you don’t hardcode database queries. Secondly, it gives you an additional layer of security. Everyone knows that the default is wp_, so choosing 239Jd_23eKSmCM892_Vuhwedp as your prefix is like adding a mini-password to your database.
• Enable debugging information
  I’ve found that a lot of sloppy developers leave undefined variables and other such nuisances all over the place. PHP might not complain about these by default, but they are annoying and could lead to other problems down the road. To make sure you don’t accidentally trigger notices, simply make sure that WP_DEBUG is set to true in wp-config.php.
• Disable WordPress script concatenation
  A more obscure feature of WordPress is the option to disable script concatenation. Sometimes, when figuring out how WordPress does things, you’ll want to look at some of the built-in JavaScript files. If you set define('CONCATENATE_SCRIPTS', false); in the wp-config.php file, your scripts will be pulled in separately. Don’t forget to reenable it for production environments!
• Advanced query analysis
  If you set the define('SAVEQUERIES', true); constant in wp-config.php, WordPress will save all of the queries performed into a variable. You’ll be able to access it by printing the $wpdb->queries variable.
• Disable the trash
  Normally a great feature, the trash just gets in the way when you’re developing and creating and deleting pages and posts. Disable the trash by setting define('EMPTY_TRASH_DAYS', 0 ); in wp-config.php.
• Test posts
  Right off the bat, I usually import the test content from the “Theme Unit Test.” This test suite contains normal posts, posts without titles, posts without content, posts with and without featured images, sticky posts, posts with a load of categories and so on. It helps you to test fringe cases especially well, which is critical for all themes.

I also like to create 16 users with different roles. Unfortunately, I don’t have a script for this, but writing one wouldn’t be that difficult. You could create an array in a file and just feed it to the wp_insert_user() function in a loop. Something like this:

    $users[0] = array(
    	'first_name'   => 'Daniel',
    	'last_name'    => 'Pataki',
    	'user_login'   => 'danielpataki',
    	'user_pass'    => 'mysupersecretpass',
    	'user_email'   => 'mysupermail@mymail.com',
    	'display_name' => 'Daniel',
    	'description'  => 'Guitar-wielding Web developer',
    	'role'         => 'administrator'
    )
    
    $users[1] = array(
    	'first_name'   => 'Viki',
    	'last_name'    => 'Makra',
    	'user_login'   => 'viki',
    	'user_pass'    => 'hersupersecretpass',
    	'user_email'   => 'hersupermail@mymail.com',
    	'display_name' => 'Viki',
    	'description'  => 'Front-end developer and awesome admin handler',
    	'role'         => 'editor'
    )
    
    foreach( $users as $user ){
    	wp_insert_user( $user );
    }
    

I actually have a set of test emails for each user account I create, and I add avatars for each of them on Gravatar. You can grab a bunch of cool images by searching for avatars on ThemeForest.

You can also use a plugin such as User Photo or Simple Local Avatars to add the photos locally.

Version Control

Version control is one of the best things to come along since bacon. Whether you prefer Git, SVN, Mercurial or another system, you will be able to roll back to different versions and always have a backup of your work lying around.

Version control is supposedly most helpful with collaboration. While this is true, I’ve found that the order it brings to your coding practice is just as valuable. I highly recommend reading Version Control With Subversion and/or Pro Git. They both have a wealth of practical information about version control, both general and specific.

During Development

Here are some useful tips and tricks to follow during theme development.

“I’ll Do That Later.”

As a seasoned coder, I usually know my way around a coding task when one arises, but pushing myself to the end of such tasks is difficult. If I am implementing a map-based search tool, then the biggest tasks are to make sure that the form works and that when the user performs a search, it hooks into Google and the results are returned and displayed on the map and so on. Once those are done, then making sure that the form looks good, that administrators can define the map type to the user and so on are minor matters.

Previously, I would work through major features and then go back and touch up the details. The only problem with this is that it is the worst practice ever. You forget things; your code gets messy; then you can’t maintain it properly; and it becomes a giant headache.

My recommendation is to either develop a feature or not. Make sure that you’ve added all planned features and that they don’t just kinda work or have bugs that are “not big problems because they can easily be fixed later.”

If your code is extremely modular, you could, of course, separate the presentation from the functionality, but that’s a story for another article.

Modularity Is King

The best way to develop is to follow the lessons of object-oriented languages or object-oriented PHP. You can’t (or might not want to) code everything with classes, but the general philosophy is very helpful.

Widgets in WordPress are a great example. Using a pretty simple pattern, you can create the back-end form for a widget and make sure that it saves its data properly and that you can add the front-end code. Then, the widget will work anywhere, anytime.

You can apply the same principles to most coding tasks. Write code that is as independent as possible. Your code will remain clean and will do wonders for maintainability.

The Right Tools

The biggest speed boosts during development come from choosing the right development tools. Below is a list of apps and other tools that speed things up a lot for me.

LESS

Almost a no-brainer nowadays, LESS or Sass should be in everyone’s tool belt. While not without criticism, these tools help way more than they harm.

A quick note about LESS. Many people really hate the idea of using LESS for CSS. While their points are valid, I disagree. But it’s up to everyone to make their own choice. Ultimately, it comes down to preference.

CodeKit

I can’t even begin to explain how much I love CodeKit. It compiles my LESS to wherever I want it to, concatenates JavaScript files based on a file input, checks syntax, and does a ton of other stuff that I never even use.

One caveat is that it is Mac-only. A ton of alternatives are available, such as Mixture, Compass and Fire.app, but none that I know of with the feature set of CodeKit.

Snippets

I don’t know if I’m alone on this, but I’ve never found snippets to be particularly useful. Most things need to be customized so much that just writing them out from scratch would be easier. There are only two snippets that I use, but I use them so much that they have saved me at least a hundred hours by now. The two snippets are for printing a variable and outputting a long comment:

    // Printing a variable:
    echo '<pre>';
    print_r();
    echo '</pre>';
    
    // A long comment:
    /*********************************************/
    /*         This is a section of code.         */
    /*********************************************/
    

I’ve set this up in Coda 2, but you can use TextExpander and various other apps.

Thumbnail Regeneration

As you code, you might find that you need a different-sized image somewhere or that the design requirements have changed. In the former case, you should generate an image with the exact dimensions you need to conserve bandwidth. You can do so with the add_image_size() function, although images would not be processed retroactively.

I use the excellent Regenerate Thumbnails plugin to address this problem. I’ll go into the “Media” section and regenerate thumbnails for a single media item, or the plugin can batch process them all. It might take a while if you have a lot of images, but it’s completely set-and-forget — you can just keep on working.

Switching Users

You’ll need to test different accounts to make sure users see only what they’re supposed to see, especially if you have role-specific functionality. User Switching is a godsend, enabling you to switch back and forth between accounts with a single click.

Template Hierarchy

The “Template Hierarchy” — and especially the diagram a bit further down on that page in the Codex — will help you to remember all of the pages you need to create. Are you sure you haven’t forgotten the 404.php page? Have you created a separate attachment.php file for single attachment display? Never forget a file again with this handy chart!

Browser Development Tools

Learning how to use your browser’s development tools will make your life a lot easier. Being able to go into the DOM and look up styles will make fixing CSS problems a breeze. Going into the “Network” tab and looking at the AJAX response will help you debug AJAX calls in seconds, and using the features of the JavaScript debugger (such as break points) will help with JavaScript debugging.

WordPress Knowledge

Being able to perform complex tasks using database queries is a huge help. If you’ve created 200 test posts and want to delete all whose titles have two instances of the word “or,” that’s easy if you know how to query and manipulate data.

It also helps with “Oh, there’s a function for that?!” syndrome, which kicks in after you’ve spent an hour coding something, only to discover that WordPress has a function for it. Some examples are the mail() function, which lets you send email easily, the wpautop() function, which adds paragraph tags to text, and the human_time_diff() function, which formats dates into the “5 minutes ago” format.

Before attempting to code a small feature, I always search for it, just in case. Before coding a big feature, I search GitHub and other places to see whether anyone has done it before. Perhaps there is a cut-and-pasteable class or something similar.

Final Testing

Once you’re done, you realize you’re never done. There’s always that one last bug, that one feature that doesn’t work in IE 9, and other similar annoyances. To minimize bugs and maximize your sanity, try the tricks and tools below.

WordPress Theme Check

WordPress Theme Check (maintained by WordPress’ own developers) is an extremely useful tool for ensuring that your theme is up to spec. The first thing Theme Forest does when you submit a theme is run this thing on it, and they will mercilessly reject your theme if they see errors.

The tool checks for legacy functions, incorrect text domains, hidden files, required functions and attributes, and much more. Using this plugin is the easiest way to make sure your theme is 100% WordPress-compliant.

CloudApp and FluffyApp

CloudApp is a service that enables you to easily upload files. The reason I love it so is that it comes with a little app that can be configured to play nice with my screenshot-making procedure. On the Mac, I just press Shift + Control + Command + 4 to take a screenshot, and then immediately press Control + Option + C (this shortcut can be reconfigured) and wait for the “ping,” which means the screenshot has been uploaded. A link to the screenshot is already in my clipboard, so I can paste it in an email, chat message or issue tracker.

If you’re on Windows, FluffyApp does exactly the same thing. I’m sure you’ll love it!

Bug-Management Workflow

I won’t go into particular bug-management tools because there are just so many. I personally use Sprint.ly, but hundreds of great services are available, such as Sifter, Lighthouse and Redmine.

More important than what you use is how you use it. One policy that has helped my team with our themes is that the person who fixes an issue may never mark it as closed or accepted. This ensures that the issue is properly tested and approved by someone who is able to see it more objectively.

Version-Control Methodology

Our version-control system gives us two other benefits. We make sure to commit after every bug is fixed; this enables us to keep track of repository changes much more easily. It also means we can roll back versions much more accurately and selectively.

We’ve tied our bug-management system to our version-control system, so that whenever we commit a change, we can close the issue right from the command line by typing, say, Fixes #32. This works in Sprint.ly and Sifter for sure.

Good Documentation

While documentation might not seem directly related to testing, it is an excellent way to test a website. By writing documentation, you force yourself to go through the website’s features and make sure they work.

We found an astounding documentation generator, which we use with all of our themes now. Aside from helping us write the documentation, it generates a beautiful format with no additional work on our end.

The More, The Merrier

One of the most important lessons I’ve learned is that a theme is never bug-free. If 100 people test the living daylights out of the theme, the 101st person (probably the first buyer) will find a bug on launch day. That’s just how it is.

You can minimize this and ensure that bugs are at least restricted to fringe cases by loosing as many people on your theme as possible. We’re all different, which means we use things differently and will find different bugs.

Another major benefit of this — one that I cannot stress enough — is that it allows for user experience testing. If only the people you work with have tested the theme, chances are you’ve missed something because you all think alike. A dropdown button might be dead obvious to all of you, but baffling to a regular user.

A great way to improve your theme is to actually sit and watch as people test your theme. I’ve made more changes than I can remember as a result of stupid things that have come up during testing — and I mean not that the people were stupid, but that I was stupid for designing those things the way I did. Remember, there is no such thing as a bad user, just a badly designed tool.

Make a Video Presentation

This sounds even weirder than documentation-based testing, doesn’t it? But I’ve found that making a presentation video about a theme is a great way to catch little things. Knowing that the first thing people will see is the video inadvertently forces you to get hung up on the tiniest problems.

The general routine for me here is that I’ll get 2 minutes into making the video, let out a huge sigh, stop the recording and go and fix something. I’ll then restart from scratch, get to 2 minutes and 15 seconds, and it all starts over.

The best method for me is to restart from the beginning after having stopped. I could instead just pause and resume, but when I start from scratch I’ll sometimes take a different approach, which uncovers more discrepancies and bugs.

Conclusion

I hope these tips have been helpful and that at least some of them are new to you. I think everyone does a lot of little things we could all learn from. I probably do 50 more useful things that I don’t even notice I’m doing.

I’d love to hear what you do to test both the quality and speed of your themes, so please share in the comments below!

(al)

© Daniel Pataki for Smashing Magazine, 2013.

Ever sketch something in pencil and want to transform it to digital art with lines of varying thickness? In this Treehouse Quick Tip, teacher Mat Helme will show you how to create a thick to thin line character illustration in Adobe Illustrator. This technique is just one of many techniques used when illustrating.

To learn more techniques like this one and to master Illustrator, be sure to check out Mat’s course, Illustrator Foundations on Treehouse!

The post How to Create a Thick to Thin Line in Adobe Illustrator – Treehouse Quick Tips appeared first on Treehouse Blog.

Everywhere you go online you see lots of tweets, Facebook posts, and Google+ updates: the social networking noise can sometimes be overwhelming. All marketers have been taught that content is king, and other variations of this statement, but no one could have imagined how much content we would produce on social media these days. 

Think of marketing reach to give you a perspective on how much noise we have created: in 1965, 80% of consumers aged 18-49 were reached via three primetime 30 second ads; by 2002, it required 117 commercials to have the same effect. When it takes 2000 impressions for one click on a Facebook ad (average CTR on Facebook is around .02-04% according to Clickz.com) then you know people do not see all the social networking noise around them. 

This challenge means that many people simply try to shout louder. Instead, we need to plan our content on social media, so we speak smarter.

How do you get above the noise?

Don’t speak to everyone

The biggest challenge entrepreneurs have when they market their business through social networking is that they want to speak to everyone. Like a kid in a candy store type of effect, they get so excited to be around so many prospects all at once. When this happens, a few people talk louder to get heard over the rest. This continues to happen, and soon you have chaos.

To end the chaos, you need to find your niche market. It is marketing 101: find a niche where you can market your services and fill in the gaps. Think of niche marketing like being in a crowded bar during happy hour. You might not get all 300 people in the bar to hear you, but everyone at your table can hear what you have to say.

Come from a place of service

When business gets tough, we sometimes go into commando sales phase. We batten down the hatches, and start reaching out to prospect after prospect after prospect until we are out of a jam. The same happens on social media. However, because it is so easy to share information, too many people share promotional information on a consistent basis.

Instead, you need to scare the living daylights of them, and provide useful information that wows them. By doing this you serve your prospects and clients. People respect how much you are willing to give of yourself to help others. Best of all, serving others not only serves as a promotional engine, but it also makes you feel proud of your business. The more pride you show in your business, the more pride others will have in referring your services to others.

Tell stories

I started using social media when I was a mortgage broker looking for new business. My wife, the techie, was convinced I could not use Facebook properly. She insisted upon setting up my account herself, because it would be “too complicated” for me to understand.

Five years later, I have helped hundreds of clients use social media, while setting up countless accounts on Facebook, Twitter, LinkedIn, Google+, and other social networks.

There is a story that is short and to the point.

Keep your network in the loop

Ever see a site go down, and all the users migrate to another hangout online, chatting up a storm about what happened? Snafus happen! They are a part of business, however, you must keep your network informed of what is occurring.

While we all want to talk to our clients about the latest and greatest at our company, sometimes an honest apology will garner more business than a success will ever achieve.

Raving fans!

This is more a result than a way to get over the social networking noise. Create raving fans of your business. People who’ve just gotta have the next iPhone, or must simply get their Starbucks kick in the morning.

When you help people, and communicate with them appropriately, you will create raving fans. There’s no magic formula for attracting raving fans, but something based upon your level of service to others. How do you go above and beyond to help others? When you know how to do this for your niche, then you know how to find raving fans.

Conclusion

Social networking has a lot of benefits to offer businesses. However, to be successful through social networking today requires a new understanding of value: how to deliver value to your prospects, partners, and clients, so they listen to you above the social networking noise.

Do you promote yourself via social media? What strategies have worked for you? Let us know in the comments.

Featured image/thumbnail, social media image by .hj barraza.

Over 4,300 Professional, High-Quality Icons – only $37!

With more people than ever writing in Sass, it bears some consideration how we format it. CSS style guides are common, so perhaps we can extend those to cover choices unique to Sass.

Here are some ideas that I've been gravitating toward. Perhaps they are useful to you or help you formulate ideas of your own.

Use Your Regular CSS Formatting Rules / Style Guide

This post is about Sass-specific stuff, but as a base to this, you should follow a whatever good CSS formatting guidelines you are already following. If you aren't yet, this roundup of style guides may help you. This includes things like:

1. Be consistant with indentation
2. Be consistant about where spaces before/after colons/braces go
3. One selector per line, One rule per line
4. List related properties together
5. Have a plan for class name naming
6. Don't use ID's #hotdrama
7. etc

List @extend(s) First

.weather {
      @extends %module; 
      ...
    }

Knowing right off the bat that this class inherits another whole set of rules from elsewhere is good.

List "Regular" Styles Next

.weather {
      @extends %module; 
      background: LightCyan;
      ..
    }

List @include(s) Next

.weather {
      @extends %module; 
      background: LightCyan;
      @include transition(all 0.3s ease-out);
      ...
    }

This visually separates the @extends and @includes as well as groups the @includes for easier reading. You might also want to make the call on separating user-authored @includes and vendor-provided @includes.

Nested Selectors Last

.weather {
      @extends %module; 
      background: LightCyan;
      @include transition(all 0.3s ease);
      > h3 {
        border-bottom: 1px solid white;
        @include transform(rotate(90deg));
      }
    }

Nothing goes after the nested stuff. And the same order as above within the nested selector would apply.

All Vendor Prefixes Use @mixins

Vendor prefixes are a time-sensitive thing. As browsers update over time, the need for them will fall away. You can update mixins (or the libraries you use will update) to reflect those changes. Even if the mixin ends up being a one-liner, that's OK.

The only time I wouldn't @mixin a vendor prefix is when it's super proprietary, unlikely to be standardized as is, and so including other vendor prefixes or the non-prefixed version is likely to cause more harm that good. I'm thinking of things like -webkit-line-clamp or -ms-content-zoom-chaining or things like that that.

Maximum Nesting: Three Levels Deep

.weather {
      .cities {
        li {
          // no more!
        }
      }
    }

Chances are, if you're deeper than that, you're writing a crappy selector. Crappy in that it's too reliant on HTML structure (fragile), overly specific (too powerful), and not very reusable (not useful). It's also on the edge of being difficult to understand.

If you really want to use tag selectors because the class thing is getting too much for you, you may want to get pretty specific about it to avoid undesired cascading. And possibly even make use of extend so it has the benefit on the CSS side of re-usability.

.weather
      > h3 {
        @extend %line-under;
      }
    }

Maximum Nesting: 50 Lines

If a nested block of Sass is longer than that, there is a good chance it doesn't fit on one code editor screen, and starts becoming difficult to understand. The whole point of nesting is convenience and to assist in mental grouping. Don't use it if it hurts that.

Global and Section-Specific Sass Files Are just Table of Contents

In other words, no styles directly in them. Force yourself to keep all styles organized into component parts.

List Vendor/Global Dependancies First, Then Author Dependancies, Then Patterns, Then Parts

So the "table of contents" things comes together like:

/* Vendor Dependencies */
    @import "compass";
    
    /* Authored Dependencies */
    @import "global/colors";
    @import "global/mixins";
    
    /* Patterns */
    @import "global/tabs";
    @import "global/modals";
    
    /* Sections */
    @import "global/header";
    @import "global/footer";

The dependencies like Compass, colors, and mixins generate no compiled CSS at all, they are purely code dependancies. Listing the patterns next means that more specific "parts", which come after, have the power to override patterns without having a specificity war.

Break Into As Many Small Files As Makes Sense

There is no penalty to splitting into many small files. Do it as much as feels good to the project. I know I find it easier to jump to small specific files and navigate through them than fewer/larger ones.

...
    
    @import "global/header/header/";
    @import "global/header/logo/";
    @import "global/header/dropdowns/";
    @import "global/header/nav/";
    @import "global/header/really-specific-thingy/";

I'd probably do this right in the global.scss, rather than have global @import a _header.scss file which has its own sub-imports. All that sub-importing could get out of hand.

Globbing might help if there starts to be too many to list.

Partials are named _partial.scss

This is a common naming convention that indicates this file isn't meant to be compiled by itself. It likely has dependancies that would make it impossible to compile by itself. Personally I like dashes in the "actual" filename though, like _dropdown-menu.scss.

Locally, Compile Expanded with Line Mapping

See here. This means dev tools can tell you exactly what file and on what line rules are coming from, even if it is an imported partial.

In Deployment, Compile Compressed

Live websites should only ever have compressed CSS.

Don't Even Commit .css Files

This might take some DevOps work, but it's pretty nice if .css files aren't even in your repository. The compilation happens during deployment. So the only thing you see in the repo are your nicely formatted hand authored Sass files. This makes the diffs useful as well. A diff is a comparison view of what changed provided by version control providers. The diff for a compressed CSS file is useless.

Be Generous With Comments

It is rare to regret leaving a comment in code. It is either helpful or easily ignorable. Comments get stripped when compiling to compressed code, so there is no cost.

.overlay {
      /* modals are 6000, saving messages are 5500, header is 2000 */
      z-index: 5000; 
    }

And speaking of comments, you may want to standardize on that. The // syntax in Sass is pretty nice especially for blocks of comments, so it is easier to comment/uncomment individual lines.

Variablize All Common Numbers, and Numbers with Meaning

If you find yourself using a number other than 0 or 100% over and over, it likely deserves a variable. Since it likely has meaning and controls consistency, being able to tweak it enmasse may be useful.

If a number clearly has strong meaning, that's a use case for variablizing as well.

$zHeader: 2000;
    $zOverlay: 5000;
    $zMessage: 5050;
    
    .header {
      z-index: $zHeader;
    }
    .overlay {
      z-index: $zOverlay;
    }
    .message {
      z-index: $zMessage;
    }

Those numbers are probably in a separate file @import-ed as a dependency. That way you can keep track of your whole z-index stack in one place.

Variablize All Colors

Except perhaps white and black. Chances are a color isn't one-off, and even if you think it is, once it's in a variable you might see uses for it elsewhere. Variations on that color can often be handled by the Sass color functions like lighten() and darken() - which make updating colors easier (change in one place, whole color scheme updates).

Nest and Name Your Media Queries

The ability to nest media queries in Sass means 1) you don't have to re-write the selector somewhere else which can be error prone 2) the rules that you are overriding are very clear and obvious, which is usually not the case when they are at the bottom of your CSS or in a different file.

.sidebar {
      float: right;
      width: 33.33%;
      @include bp(mama-bear) {
        width: 25%;
      }
    }

More on this and the importance of naming them well.

Shame Last

In your global stylesheet, @import a _shame.scss file last.

@import "compass"
    
    ...
    
    @import "shame"

If you need to make a quick fix, you can do it here. Later when you have proper time, you can move the fix into the proper structure/organization. See more.

Final Output Is On You

Sass doesn't do anything you don't tell it to do, so claiming that Sass output is bloated is just claiming that you write bloated code. Write Sass such that the final CSS output is just as you would have written it without Sass.

Need a new look for your portfolio? Check out the Snap WordPress theme from The Theme Foundry. Sass files and Compass config are included!

Sass Style Guide is a post from CSS-Tricks