Wptuts+

Using CSS Preprocessors With WordPress – LESS + CodeKit

Jason Bradley — Thu, 23 May 2013 12:37:36 +0000

This entry is part 2 of 2 in the series Using Preprocessors With WordPress

In the first part of this series I gave a quick overview of the popular CSS preprocessors LESS and SASS. I also shared a few of the frameworks in which they are used.

I plan on taking a deeper dive into LESS and talking about the parts of the language I use most often. I also plan on showing you how to get started using it with CodeKit.

Let’s dig in!

What I Use and Why

I personally use LESS for most WordPress projects. I spend a lot of time working with Standard and it uses Bootstrap as its framework of choice.

Since Bootstrap uses LESS for compiling its CSS, I have learned how to use its .less files to make modifications. I know of other web designers and developers who prefer to use Foundation. Since Foundation uses SASS, they have learned to use that instead.

I am personally starting to work on another web project that uses SASS, and it has been relatively easy to pick things up due to my experience with LESS.

A Look at LESS

Variables

Variables are pretty self-explanatory. You can create a variable somewhere in your .less file and then reference it in other places in that file, or other files. I tend to use it for colors, fonts, padding, and margins.

Here’s an example:

// Variables
@red: #ff0000;
@green: #00ff00;
@blue: #0000ff;

// Styling

// Links
a { color: @blue; }
a:visited { color: @blue; }

That will then compile to this:

a { color: #0000ff; }
a:visited { color: #0000ff; }

If you wanted to change the color of both link stylings, then you just need to change the variable:

@blue

from

#0000ff

#0000a4

You change in one spot, recompile, and you have changed all instances of that variable throughout the file.

Another great way to use these variables as well would be to use more semantic naming like:

@primaryColor

and

@secondaryColor

You can then use those variables throughout your code. When your designer comes up with those colors, you can just change them once, recompile, then you’re done!

Nesting

Nesting is used just like you would nest logic in an if/else block in your PHP or JavaScript: You set your higher level selector like .post, then place the other selectors inside of it. It will eliminate the need to repeatedly type out .post in front of your other selectors like so:

// Post
.post {
	padding: 20px;
	.post-header {
		margin: 20px 0;
	}
}

That will then compile to this:

.post { padding: 20px; }
.post .post-header { margin: 20px 0; }

You can also use & to concatenate selectors as well. An example could be if you wanted to target specific widgets in your sidebar. Let’s say you wanted to style the background color of Recent Posts and Recent Comments widgets differently. You can do the following in LESS:

.widget {
	padding: 20px;
	&.widget_recent_entries {
		background-color: white;
	}
	&.widget_recent_comments {
		background-color: black;
	}
}

That would compile into this:

.widget { padding: 20px; }
.widget.widget_recent_entries { background-color: white; }
.widget.widget_recent_comments { background-color: black; }

You can also use this for pseudo classes like :hover, :active, :visited, :before, and :after.

// Links
a {
	color: blue;
	&:hover {
		color: red;
	}
	&:visited {
		color: red;
	}
}

That would compile to this:

a { color: blue; }
a:hover { color: red; }
a:visited { color: red; }

Mixins

Mixins are basically a number of style attributes that you want to group together. A great example of this is for attributes that are different between browsers like border radius.

Instead of having to remember each one, you can call your mixin and it will provide each attribute for you. Here’s an example:

// Mixin
.border-radius {
	border-radius: 4px;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}
// Widget
.widget {
	.border-radius;
}

That will compile to the following:

.widget {
	border-radius: 4px;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}

What if you wanted to use border radius multiple times in your .less file but wanted different amounts for each? That’s when you would use a Parametric Mixin.

This simply means that you can reuse a mixin and pass it an argument to use. Here’s an example:

// Mixin
.border-radius (@radius: 4px) {
	border-radius: @radius;
	-moz-border-radius: @radius;
	-webkit-border-radius: @radius;
}

// Widget
.widget {
	.border-radius();
}

// Post
.post {
	.border-radius(8px);
}

That would compile to this:

.widget {
	border-radius: 4px;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}
.post {
	border-radius: 8px;
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
}

Putting It All Together

Here’s an example of using variables, nesting, and mixins all at the same time:

// Variables
@widget-recent-posts-border-radius: 4px;
@widget-recent-posts-background-color: white;
@widget-recent-posts-link-color: @blue;

@widget-recent-comments-border-radius: 8px;
@widget-recent-comments-background-color: black;
@widget-recent-comments-link-color: @red;

// Colors
@blue: #0000ff;
@red: #ff0000;

// Mixins
.border-radius (@radius: 4px) {
	border-radius: @radius;
	-moz-border-radius: @radius;
	-webkit-border-radius: @radius;
}

// Widgets
.widget {
	&.widget_recent_entries {
		background-color: @widget-recent-posts-background-color;
		.border-radius(@widget-recent-posts-border-radius);
		ul li a {
			color: @widget-recent-posts-link-color;
		}
	&.widget_recent_comments {
		background-color: @widget-recent-comments-background-color;
		.border-radius(@widget-recent-comments-border-radius);
		ul li a {
			color: @widget-recent-comments-link-color;
		}
	}
}

Which would all compile into this:

.widget.wiget_recent_entries {
	background-color: white;
	border-radius: 4px;
	-moz-border-radius: 4px;
	-webkit-border-radius: 4px;
}
.widget.widget_recent_entries ul li a { color: #0000ff; }
.widget.wiget_recent_comments {
	background-color: black;
	border-radius: 8px;
	-moz-border-radius: 8px;
	-webkit-border-radius: 8px;
}
.widget.widget_recent_entries ul li a { color: #ff0000; }

Using CodeKit

Importing a Project

It’s extremely easy to setup your CodeKit Project. You can simply drag and drop your folder into CodeKit, or you can click the plus button in the bottom left and then select a folder from the file browser.

Once you do that, CodeKit will automatically scan all the files in that folder and then group them into the following categories:

Styles
Scripts
Pages
Images

Configuring the Project

So you have now imported your project files. Next we are going to set the output path of your .less files. I would suggest to have a css folder and a less folder inside of it. You will want to make sure to have all of your files in that less folder to point to your style.less file.

You will want to switch over to the Styles view. We will want to have the style.less file be compiled into your theme’s root folder as style.css. To do this, you will want to right-click on the style.less file, and select “Set output path…“. This will bring up a File Browser.

Next, you will want to click in the Output filename and extension text input. Once you do that it may auto populate style.css for you. If it doesn’t, then you will want to enter in style.css. Lastly you will click on Select to save.

We are almost there! Next we will need to select a compilation setting. You will see the compilation settings screen reveal itself when you click on a .less file. We have three available output styles:

Regular
Minified
Compressed (YUI)

Select one of the above and click on “Compile“. You should get a notification that your style.less file has compiled.

If all of your syntax is correct, your compile will be successful. If there are any errors, it will flip you over to the Log view and give you the line number and explanation of the error.

If everything compiles correctly, you should be able to open up your style.css file and see the output. As you edit your .less files and save them, CodeKit will automatically recompile your files.

Note: Make sure that you don’t make any changes to the style.css file, because as soon as you recompile your .less files, your changes will be overridden.

Conclusion

We have now gone through a deeper dive into LESS and broken down a few of the popular features. I have explained a few reasons why I personally choose to use LESS in my WordPress projects and how to use CodeKit to compile all of my files.

In the next post, I will go into greater detail around how to structure your ‘.less‘ files and connect them all together.

Resources

Win a Ticket to Our New Tuts+ Live Workshop

Joel Bankhead — Wed, 22 May 2013 14:45:17 +0000

We have 5 tickets to give away for our newest Tuts+ Live Workshop, all you have to do is subscribe to our newsletter. Be quick though, this giveaway ends on Monday!

We have a superb new Workshop, Introduction to WordPress Plugin Development, starting in a week. This is your chance to win a free ticket!

Simply subscribe to the Tuts+ Live Workshops newsletter and we’ll pick the winners on Monday 27th. Read on to find out more about the Workshop and for more details about the giveaway!

Introduction to WordPress Plugin Development

Our newest Tuts+ Live Workshop, Introduction to WordPress Plugin Development, teaches you everything that you need to know to start developing WordPress plugins; from setting up a local development environment, all the way through to building a WordPress plugin that’s ready for release into the WordPress Plugin Repository.

It’s led by Instructor Tom McFarlin, a self-employed WordPress developer who divides his time between running his own WordPress development shop, building plugins for WordPress, blogging every day about software development in the context of WordPress, and working for 8BIT (the team responsible for Standard Theme and WP Daily).

Each weekly workshop will last one hour, running over a five week period. You’ll have the opportunity to follow along with Tom, ask questions live during the workshop, and complete a weekly homework assignment. Not able to make it to the live recording? No problem! All of the workshop recordings will be made available online the day after the live workshop.

Learn more about Introduction to WordPress Plugin Development

Subscribe and Win a Ticket!

We have 5 tickets to give away and will be choosing the winners from everyone who has subscribed to the Tuts+ Live Workshops newsletter, so no worries if you’ve already signed up. We’ll also reimburse any winners who have already paid for their ticket.

To enter simply subscribe to the Tuts+ Live Workshops newsletter and stay informed on upcoming workshops!

Design Patterns in WordPress: We’re Just Getting Started

Tom McFarlin — Tue, 21 May 2013 12:26:36 +0000

This entry is part 4 of 4 in the series Design Patterns in WordPress

Throughout this series, we’ve been taking a look at a few design patterns and how they are applicable to software development – specifically WordPress development.

The thing about design patterns is that there is a wide variety of them and it would be near impossible to do justice to each of the patterns in a series here on the blog. Nonetheless, hopefully taking a look at these three have helped kickstart your interest in using design patterns in your work.

To wrap up this series, I wanted to provide a list of other patterns, resources, and guides that you may find useful if you’ve found this particular series useful in your development endeavors.

A List of Design Patterns

Here’s the thing: The list of design patterns isn’t fixed. There are some that have been established for quite some time.

The truth is, the patterns even have various permutations based on the environment in which they’re implemented – this is why I think it’s so important to understand the core pattern so that you can adapt it to your needs, or so you can recognize it in the wild so that – should the need arise – you can continue to implement your work in a way that plays nicely with the existing implementation.

With that said, I can’t possibly list out all of the design patterns here. I can list out many of the popular patterns along with some links to their corresponding Wikipedia articles so you have a few to review.

The Abstract Pattern
The Singleton Pattern
The Adapter Pattern
The Composite Pattern
The Decorator Pattern
The Flyweight Pattern
The Chain-of-Responsibility Pattern
The Null Object Pattern
The Visitor Pattern
The Scheduler Pattern
For a more comprehensive list, check out this page.

For those that are listed above, I recommend at least reading through each of the articles. Many of the them will likely be applicable to your day-to-day work especially if you’re working on larger applications. Even if you’re working on a smaller project, they’re still applicable and beneficial.

After that, we’ll take a look at two books that I highly recommend for developers to have on their desk at any given time.

Resources

Whenever others ask me for resources on design patterns, there are really only two books that I recommend. Both of them are listed below along with links, a short description of each, why I recommend them, and the target audience for each of them.

Head First Design Patterns

Head First Design Patterns is a relatively new book in comparison to a lot of the material that’s available today. It uses a different teaching style than many classical books or text books in that it uses a lot of humor, lots of pictures, diagrams, humor, and so on.

Personally, I’m a fan of its style but I know that some may reject it.

Nonetheless, the book covers the following patterns:

The Strategy Pattern
The Observer Pattern
The Decorator Pattern
The Simple Factory Pattern
The Factory Pattern
The Singleton Pattern
The Command Pattern
The Adapter Pattern
The Facade Pattern
The Template Method Pattern
The Iterator Pattern
The Composite Pattern
The State Pattern
The Proxy Pattern
The Compound Pattern
And a list of other common patterns that we’ve listed in the first part of this article.

If you’re looking for a book to get started in design patterns, then this is the book with which I’d start.

Design Patterns: Elements of Reusable Object-Oriented Software

This book is also known as The Gang of Four Book because it was written by four accomplished software engineers. It’s a more technical read than Head First Design Patterns, but I still recommend it as the description of the patterns and the provided diagrams and implementations are easy to follow.

I will say that if you’re just now venturing into the world of design patterns, I’d start with Head First and then read this book; otherwise, this one may seem a bit more dry or less interesting.

Nonetheless, here’s the list of patterns the Gang of Four provide in their book:

The Abstract Pattern
The Builder Pattern
The Factory Pattern
The Prototype Pattern
The Singleton Pattern
The Chain of Responsibility
The Command Pattern
The Interpreter Pattern
The Iterator Pattern
The Mediator Pattern
The Memento Pattern
The Observer Pattern
The State Pattern
The Strategy Pattern
The Template Method Pattern
The Adapter Pattern
The Bridge Pattern
The Composite Pattern
The Decorator Pattern
The Facade Pattern
The Flyweight Pattern
The Proxy Pattern

In addition to covering the patterns, the book also uses case studies to show actual implementations of the pattern in real world examples which I think can be incredibly useful when referring to them in your work.

Conclusion

One of the dangers for people who first discover design patterns is the propensity to try to apply them everywhere, but don’t do that: design patterns offer a lot of advantages in software development, but they have their place and things should not be forced into a pattern.

They should fit naturally.

In short, don’t try to use patterns for the sake of using a pattern, use them when their design fits the problem that you’re trying to solve.

With that said, we’ve wrapped up the Design Patterns in WordPress series.

To summarize:

We’ve covered the Observer Pattern and how we can setup our code to fire events and to publish them to other objects that are interested.
We’ve reviewed how to setup our plugins so that a single instance of the plugin is always accessible throughout the lifetime of the plugin, theme, or application
We also took a detailed look at the Simple Factory pattern that included a demo application, diagram, and sample code

All in all, it feels as if we’ve covered a lot of ground. The truth is, there’s still much to review. If you’ve found this particular series interesting, or want to take a deeper dive into the topics at hand, be sure to review the design patterns listed earlier in this article, or read the two books that are linked above.

Using CSS Preprocessors With WordPress – What Are They?

Jason Bradley — Mon, 20 May 2013 14:32:45 +0000

This entry is part 1 of 2 in the series Using Preprocessors With WordPress

I’ve been working with WordPress for three years, but it wasn’t until a year ago that I got serious about WordPress development. Specifically, I’m passionate about child theming and spend much of my time working in theme development.

During the past couple of years, we’ve seen the rise of CSS preprocessors – mainly, tools that make writing stylesheets easier and make them more maintainable.

In this series, we’re going to take a look at what preprocessors are, what popular ones are available, and how we can integrate them into our theme development.

Where We’re Headed

When it comes to user-interface development, it’s not just about how to make things look great, but it’s also about making things well-structured and as performant as possible, and I believe that this should be something that’s pulled through in our WordPress projects, as well.

In this series, I plan on giving a little background on what preprocessors are and highlight some of the key players in the space. I will also talk about some of the more popular frameworks. I will then move on to more of a deep dive into LESS and explain why I prefer using it. Lastly I will cover how to use it with CodeKit to compile your CSS for your theme.

About CSS Preprocessors

As mentioned, there are a number of CSS preprocessors, the most commonly used being LESS and SASS. Both are syntactically similar and can dramatically increase the speed at which you can write your CSS.

There are a few differences like their compilers and extensions or frameworks with which they can be combined.

LESS

LESS is a dynamic stylesheet language. You can write your CSS programmatically in a .less file and compile your output into a .css file. The compilation language for LESS is JavaScript. This a great because you can run the compiler on the server side or client side.

Some of the features of LESS include:

Variables – Variables can be defined and are used throughout your file. Make a change in one place and see it updated wherever it’s used.
Mixins – Mixins include a bunch of properties from one ruleset into another ruleset. You can also use Parametric Mixins that accept arguments.
Nested Rules – Nested Rules give you the ability to use nesting instead of, or in combination with cascading.
Namespaces – Namespaces allow you to group your variables or mixins, for organizational purposes, or just to offer some encapsulation.

I will be going into more detail on the syntax for these in the next post in this series.

Two of the more popular front-end frameworks that use LESS are:

SASS

SASS is an extension of CSS3. It has two syntaxes: .scss and .sass. .SCSS is the most common syntax used but it also supports the older indented syntax.

Some of the features of SASS include:

Variables – Variables can be defined and are used throughout your file. Make a change in one place and see it updated wherever it’s used like LESS.
Mixins – Mixins allow you to re-use whole chunks of CSS, properties or selectors like LESS
Nesting – Avoid repetition by nesting selectors within one another like LESS
Selector Inheritance – It can tell one selector to inherit all the styles of another without duplicating the CSS properties. Not available in LESS.

Here’s a few frameworks that include SASS and SCSS:

Conclusion

CSS Preprocessors are definitely a growing trend in web design. They can dramatically speed up the time you spend on writing styles for your sites.

They can also help with structuring your CSS like you would functions in other languages like PHP or JavaScript. If you aren’t already using CSS preprocessors in your web project, you should definitely consider it.

Now that we’ve taken a look at two of the more popular preprocessors, I’ll take a deeper dive into LESS and give some reasons why I personally choose to use it in the next post. I will also show you how to get started with using CodeKit with your WordPress projects.

Resources

Take Your Skills to the Next Level, Build Your Own Plugins

Joel Bankhead — Sat, 18 May 2013 15:30:35 +0000

There are only a few Early Bird tickets left for our fantastic new workshop led by Instructor Tom McFarlin: Introduction to WordPress Plugin Development

Are you an aspiring WordPress developer? Are you ready to take the next step and start building your own custom plugins for WordPress? Our newest Tuts+ Live Workshop is the perfect way to get started!

Tom is going to teach you how to write a WordPress plugin that connects to the is.gd API in order to implement an alternative URL shortner to the built-in wp.me shortner.

The goal of the plugin is to demonstrate:

How to write an object-oriented based plugin.
How to interface with a third-party API.
How to introduce a custom meta box.
How to perform input validation and sanitization.

Early Bird tickets are half-price at only $49, but places are strictly limited so act fast to make sure you don’t miss out!

Introduction to WordPress Plugin Development

Learn more about Introduction to WordPress Plugin Development

Grab an Early Bird Ticket Now!

We’re offering a special Early Bird price of $49, but these tickets are limited. Once the Early Bird tickets have disappeared, the workshop will be $99.

If you’re interested in future workshops then definitely join the Tuts+ Live Workshops mailing list to stay posted on upcoming workshops and get notified as soon as they’re available, the Early Bird tickets for our previous workshops have all sold out, so it’s worth getting ahead of the game!

We’re really excited about new workshop, Introduction to WordPress Plugin Development, but places are strictly limited so act fast to make sure you don’t miss out!

Design Patterns in WordPress: The Simple Factory Pattern

Tom McFarlin — Fri, 17 May 2013 13:34:36 +0000

This entry is part 3 of 4 in the series Design Patterns in WordPress

In this series, we’re taking a look at design patterns and how we can leverage them to our advantage when building products on top of WordPress.

The nice thing about design patterns is that they aren’t explicitly limited to themes or plugins – they are handy in a variety of different scenarios. It’s simply a matter of being able to identify which patterns are applicable to certain scenarios.

In the last post, we reviewed the Singleton Pattern. In this article, we’re going to take a look at the Simple Factory Pattern which is especially useful when you have a number of different classes each of which has a unique purpose and solves a specific problem.

In this post, we’ll take a look at another pattern – the Simple Factory Pattern – which is useful when you have a number of classes each of which has a unique purpose and that can be selected based on certain criteria.

The Factory Method Pattern

The Simple Factory Pattern is actually derived from a pattern known as the Factory Method Pattern which is a slightly more complicated version of the pattern that we’re going to be reviewing.

According to Wikipedia, the Factory Method pattern is defined as follows:

The factory method pattern is an object-oriented creational design pattern to implement the concept of factories and deals with the problem of creating objects (products) without specifying the exact class of object that will be created

Sounds a bit complicated, doesn’t it?

The truth is, it’s actually a really powerful design pattern but it would take a much longer article to discuss it, and it’s a bit out of scope for the purpose of this series.

So, as mentioned, we’re going to take a look at a version of the pattern that’s paired down a little bit and should be more generally applicable to less complicated projects.

Before we do that, let’s come up with a definition of the Simple Factory Pattern:

The Simple Factory pattern returns a specific set of data or a specific class based on its input.

Ah the risk of making a pun, simple, right?

A Note About the Simple Factory Pattern

The truth is, many software engineers refer to the Simple Factory more as an idiom than a full-blown pattern; others consider this a pattern.

For what it’s worth, I see it as a very simple pattern. It has a specific use case that can be easily identified when to use it during the course of development which we’ll review later in this article.

Regardless, I bring this up so that if you see this used as an idiom (or a pattern) used throughout various articles on the Internet, or even in conversation, you’ll know that the developers in question are referring to the same programming strategy – just in a different way.

So Why Does This Matter in WordPress?

Just as design patterns in non-WordPress specific projects, such as larger applications, the design patterns provide a tried and true way to solve a common problem.

It helps to abstract our code a bit, keep our project easily maintainable, easily readable, and can actually help us to keep our code lean. This may result in us actually having more files in our project, but each file should have fewer lines of code.

This means that each file should have a specific purpose that should be clear, not only to us, but future developers as well.

What It Looks Like

Now, before we dive into the diagrams, talking about classes, and the strategies required to implement the actual pattern, I want to mention that we’re going to be taking a simple approach to this.

The thing is, the readership of this blog spans a wide array of experiences – we have some people who are learning to write code; others who are seasoned veterans.

In order to appeal to the majority of the readership, we need to strike a balance. So for those of you who have been involved with software engineering for years, this may seem overly simplistic; however, don’t skim it – perhaps you’ll pick up something new.

For those of you who are beginners or even intermediate programmers, pay close attention to what we’re discussing as it can provide dividends in future (or even existing) work.

The Purpose of the Simple Factory

So imagine this scenario: You’re working on a function that takes in a set of input – usually some type of unique string or integer – and you have this long if/else statement or perhaps you have this large switch/case statement that continues to grow as your project grows.

The problem is that the conditionals become a pain to manage. In fact case conditionals, or the case blocks, may actually end up doing as much work as a certain function should do.

This is where the Simple Factory comes into play. What we can do is abstract the details happening in each of the conditionals into their own class thus making it much easier to maintain and keeping the code much leaner.

And that is the Simple Factory Pattern.

A Look at the Pattern

So here are the key features of the Simple Factory Pattern:

Notice that the Plugin class has a private reference to the Factory class
The Factory class encapsulates all of the logic to return an object of the type User
The User class is a base class for three other classes: Admin, Volunteer, Reader, and the idea is that each of these types are subclasses of users with unique functionality of their own
The Plugin will receive a certain type of input that it will pass to the Factory
The Factory will examine the input and then, based on its value, will return one of the three user types

Nothing too complicated, right? Honestly, I think that the diagram is a bit more complicated than the principles at play. It really provides a lot of flexibility especially whenever you’re looking to introduce another User type like an Editor or something similar.

Note: This is not to be confused with WordPress’ built-in user types. This is simply an example to show what the pattern would look like.

A Working Example

Now that we’ve taken a look at the diagram for the pattern, let’s take a look at the source code in action. Below, we’ll look at the source code for each class and then I’ll provide a download to a fully documented demo after the discussion.

The Plugin

First, let’s look at the plugin class. Remember, this is nothing more than a prototype of what the pattern looks like. It’s not the same thing as a fully developed WordPress plugin.

<?php

include_once( 'simple-factory.php' );

class Plugin {

	private $factory;

	public function __construct() {
		$this->factory = new Simple_Factory();
	}

	public function get_user( $permission ) {
		return $this->factory->get_user( $permission );
	}

}

?>

Notice that the plugin is relatively simple:

It includes the simple-factory.php script in the header of the file
It then defines a constructor in which it sets the $factory property to an instance of the Simple_Factory
The only method available in the plugin is get_user which returns a user based on a type

We’ll see how this comes into play after we’ve examined all of the other classes.

The User

The User is an abstract base class that provides a basic constructor and an abstract function that must be implemented by all other subclasses.

<?php

abstract class User {

	private $role;

	public function __construct( $role ) {
		$this->role = $role;
	}

	abstract public function get_role();

}

?>

Note that this class is intended to be subclassed by a variety of other classes, each of which we’ll look at in detail momentarily.

The Administrator, The Reader, and The Volunteer

The following four classes are all separate files each of which subclass the User base class. I’ve opted to include them all here together because there’s so little deviation from their actual implementation that it should be easy enough to follow.

The Administrator

<?php

class Admin extends User {

	public function __construct() {
		$this->role = "Administrator";
	}

	public function get_role() {
		return $this->role;
	}

}

?>

The Reader

<?php

class Reader extends User {

	public function __construct() {
		$this->role = "Reader";
	}

	public function get_role() {
		return $this->role;
	}

}

?>

The Volunteer

<?php

class Volunteer extends User {

	public function __construct() {
		$this->role = "Volunteer";
	}

	public function get_role() {
		return $this->role;
	}

}

?>

As usual, leave me questions in the comments; otherwise, review the code then be sure to read up on The Simple Factory which is the next section – it ties all of this together.

Also, remember that all of this code will be shared at the end of the article along with code comments that describe exactly what’s happening.

The Simple Factory

The Simple_Factory class is really the crux of the entire pattern. Here is where all the decisions are made and the appropriate objects are returned.

<?php

include_once( 'users/user.php' );
include_once( 'users/admin.php' );
include_once( 'users/volunteer.php' );
include_once( 'users/reader.php' );

class Simple_Factory {

	public function get_user( $permission ) {

		switch( strtolower( $permission ) ) {

			case 'read-write':
				$user = new Admin();
				break;

			case 'help':
				$user = new Volunteer();
				break;

			case 'read':
				$user = new Reader();
				break;

			default:
				$user = null;
				break;

		}

		return $user;

	}

}

?>

Note that the Simple_Factory includes the base user class and its subclasses and then works to return the appropriate type of user based on the incoming set of permissions.

The Advantages of the Simple Factory Pattern

Though it should be a bit obvious by this point in the article, the Simple Factory Pattern provides a number of advantages especially if you’re used to working with large conditionals.

It provides an elegant way to abstract your code so there’s less visual clutter
It allows you to introduce specialized, focused classes with a single purpose (which is great if you follow the SOLID principles)
It makes the code more maintainable as there’s a single place where classes are instantiated, and each class serves a single purpose

Overall, this is one of my favorite patterns simply for the matter of code organization and specialization that it can bring to the table.

Conclusion

Finally, you can checkout the entire source code – complete with documentation and installation instructions – on GitHub using this link.

At this point, we’ve taken a look at three patterns:

The Observer Pattern
The Singleton Pattern
The Simple Factory Pattern

This series could go one for a while; however, I think that we’ve covered enough ground at least to get many of us started with implementing patterns into our work.

So in the last article in the series, we’ll recap what we’ve learned and I’ll also recommend some other patterns, their purpose, and some further points of research that should continue to aid you in continuing to learn about design patterns and their advantages not only in WordPress development, but general software development, as well.

Quick Tip: After the Content – Share This

Barış Ünver — Thu, 16 May 2013 12:47:51 +0000

This entry is part 7 of 7 in the series After the Content

If we’re saying that content is “king”, social media might as well be the “queen”. We can safely claim that social media is the most efficient way to spread the content around the web, in our time.

In this post, we’re going to cover how and why we should include a “Share This” section with our content.

“Share This” for Instant (And Free) Content Promotion

In the golden era of social media, it would be silly not to encourage people to share your content on social networks like Facebook, Twitter, Pinterest, or Google+.

Yes, we live in a social world and it’s not just something we do among our friends. I wrote this quick tip in Turkey, my editor published it in Australia and while a German reader gave it a five-star rating, an Iranian reader shared this quick tip on Twitter and a Korean friend of his retweeted his tweet. Just ten years ago, this wasn’t possible at all.

Think of this example and think about your own blog. It doesn’t have to be an international magnificance but you can reach a serious amount of people with the power of social media. With WordPress, it’s ridiculously easy to go viral – as long as you create quality content and allow your visitors to share that quality.

Plugins to Offer a “Share This” Section

As you can imagine, creating a “Share This” section manually is relatively easy. You could just get the “widget codes” of the social networks you like and replace the URLs with <?php the_permalink(); ?> and <?php the_title(); ?> inside the widget code, if necessary.

Then it’s all HTML:

<div class="share-this">
	<div class="twitter"><!-- The widget code --></div>
	<div class="facebook"><!-- The widget code --></div>
	<div class="google-plus"><!-- The widget code --></div>
</div>

But there’s an even easier way to create this section: with plugins. These plugins will most probably suffice for your blog and will fit your theme like a glove:

Jetpack by WordPress.com – WordPress’ own “feature pack” comes with a variety of little plugins, including a sharing section which provides an elegant bar at the bottom of your posts, right after the post content. If you’re already using Jetpack (like me), this is probably the best solution for you.
Digg Digg – Digg Digg might be considered as a “more comprehensive solution” for sharing, in comparison to Jetpack’s share buttons. It allows you to put the buttons before or after the content, or even as a floating bar along with the content. It also lets you choose big or small buttons to fit better with your design. If you like to take control with many, many options, this plugin is right for you.
Share Buttons by AddThis – It looks like yet another plugin that gives you share buttons. However, along with a membership on AddThis.com, this plugin shows you in-depth analytics of how your content is shared. If you’re interested in your content’s sharing statistics, this is the plugin you should use.

There are, of course, many more share plugins out there and you may find some of them even better than the big guys above. My personal choice is Jetpack, but that’s because I use many other features of the plugin along with the share buttons.

I recommend experiencing as many choices as possible (including the one with just HTML) and decide which one is the best based on your findings.

Conclusion

As I said before, we’re communicating in a social web now. If you want people to reach you, you have to provide share buttons for your content, “the king”.

Do you think there are better plugins (or non-plugin solutions) about social sharing sections worth mentioning? Post your comments below – it’s always important for you to share your thoughts with us!

Design Patterns in WordPress: The Singleton Pattern

Tom McFarlin — Tue, 14 May 2013 13:45:00 +0000

This entry is part 2 of 4 in the series Design Patterns in WordPress

Throughout this series, we’re taking a look at the significance of design patterns and the roles that they play in WordPress development.

In the first post in the series, we took a high-level survey and even reviewed the Observer Pattern to see how it’s possible to register various functions or objects with certain events that occur within the lifecycle of an application.

In this post, where’s going to take a look at the Singleton Pattern.

Specifically, we’re going to take a look at the definition of the pattern and how it works, we’re going to review a diagram of what the architecture of the pattern looks like, we’ll cover some sample code for the pattern, and then we’ll discuss the advantages of the pattern as it relates to WordPress development.

The Singleton Pattern

Wikipedia defines the Singleton Pattern as follows:

In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object.

Perhaps a simpler way of explaining the pattern is this: The Singleton Pattern ensures that a class can only have one instance and it provides a single way to retrieve an instance of itself.

So Why Does This Matter in WordPress?

As far as theme development is concerned, I personally don’t see much of a use for it unless you’re bundling some type of helper class or library with your theme; however, if you’re building plugins, then this can be exceptionally useful.

As of now, there are really only a handful of ways to instantiate plugins (excluding widgets – that’s another topic) within WordPress:

You can instantiate the plugin at the bottom of your plugin file, but this can lead to an orphaned object
You can stick the plugin in the PHP $GLOBALS collection, but this can be dangerous as you could trash something that already exists or it’s making the collection needlessly larger
If you instantiate it with, say, each page load then the data isn’t being persisted unless you serialize and hammer the database each time the plugin is instantiated

None of the above are particularly good strategies (although you could make a case that they all work).

However, we care more than just getting something to work, right? We want it to work and we want an elegant solution to the problem. This is where design patterns – more specifically, the Singleton Pattern – come into play.

What It Looks Like

First, let’s take a look at a diagram of the Singleton Pattern. Check out the diagram below, then we’ll talk about the specifics after the image:

So here are the key features of the Singleton Pattern:

There is a private, static instance variable defined in the attributes that is used to maintain a reference to the class
The constructor has been marked as private
There is a public static function named get_instance which is used to return an instance of the class

Nothing too complicated, but I think reviewing the code for the Singleton Pattern goes a long way in making it a bit clearer, so let’s do that now:

class Foo {

	/*--------------------------------------------*
	 * Attributes
	 *--------------------------------------------*/

	/** Refers to a single instance of this class. */
	private static $instance = null;

	/*--------------------------------------------*
	 * Constructor
	 *--------------------------------------------*/

	/**
	 * Creates or returns an instance of this class.
	 *
	 * @return	Foo	A single instance of this class.
	 */
	public static function get_instance() {

		if ( null == self::$instance ) {
			self::$instance = new self;
		}

		return self::$instance;

	} // end get_instance;

	/**
	 * Initializes the plugin by setting localization, filters, and administration functions.
	 */
	private function __construct() {

	} // end constructor

	/*--------------------------------------------*
	 * Functions
	 *--------------------------------------------*/

} // end class

Foo::get_instance();

Obviously, there’s been a lot of code left out of the above class, but the pattern’s principles remain.

Notice that we have a private, static instance variable that’s used to refer to this class. Specifically, it’s set in the get_instance function whereas the constructor has been marked as private.

Typically, when instantiating classes, the constructor is the function that is called whenever we initialize classes; however, in this case, the constructor is marked as private.

So what gives?

Notice that we have a public get_instance function just above the constructor. This function literally checks to see if the static instance variable is null and, if so, creates a new instance of the class (which it can do since it’s within the context of the class); otherwise, it returns the current instance.

This is how no more than a single instance of a class is created.

Finally, note that we instantiate the class not with the standard new keyword, but by calling get_instance. Not only that, but we also get future references to the class by using the same method.

So, for example, let’s say that you’re working in another template and you need to call a function – say bar() – that exists in your plugin. In that case, you’d do something like this:

$foo = Foo::get_instance();
$foo->bar();

Pretty neat, isn’t it?

The Advantages of the Singleton Pattern

Despite the fact that we’ve covered the Singleton Pattern from an architectural and a practical standpoint, we haven’t actually talked about the advantages of the pattern.

Generally speaking:

The Singleton Pattern prevents other objects or clients from duplicating instances of the class. This makes sure that there’s only one copy of the data maintained at any given time. All access to the object is done so by the single instance.
We have a wide array of flexibility when it comes to implementation because we can actually impact the instantiation process (though this is a bit out of scope for this particular post).

Perhaps the largest drawback from using the pattern is lack of clarity that the plugin actually uses the pattern. If someone tries to instantiate the class, instantiation will fail because there’s no public constructor.

As such, documentation is key.

Conclusion

Whether you’ve seen them before or this is your first foray into design patterns, the Singleton Pattern is arguably the simplest design pattern there is. It’s easy to implement, and it provides a significant source of functionality when implemented correctly especially as it relates to web applications.

In the next post, we’ll take a look at another pattern – the Simple Factory Pattern – which is useful when you have a number of classes each of which has a unique purpose and that will be needed based on certain input criteria.

Design Patterns in WordPress: An Introduction

Tom McFarlin — Fri, 10 May 2013 12:23:48 +0000

This entry is part 1 of 4 in the series Design Patterns in WordPress

For those who have an extensive background in software engineering, design patterns should be familiar territory; however, there’s an entire group of developers – especially in the web development community – who aren’t necessarily familiar with design patterns (even though they’ve likely used them!).

In this series, we’re going to take a look at design patterns, specifically in the context of WordPress, how they’re useful, and some practical examples that we can use in our themes and plugins.

The ultimate goal of the series is to provide a solid definition of what design patterns are, why they’re useful, how they’re used in WordPress core, and then review two popular examples that we can easily employ in our own work.

Before we get to taking a look at some practical examples, let’s define design patterns, and look at an example of how they are used in WordPress core.

Design Patterns Defined

For those of you who have never heard of or who have never used design patterns, it’s important to understand what they are before we actually begin using them in our work.

Wikipedia provides the following definition:

A design pattern in architecture and computer science is a formal way of documenting a solution to a design problem in a particular field of expertise. An organized collection of design patterns that relate to a particular field is called a pattern language.

Perhaps a more simplified definition would be:

A pattern is a design that can be applied to a problem in a specific situation.

If that’s still not clear, think of it this way:

Whenever you’re building a piece of software, you’re likely to recognize that you’re solving a problem that you’ve already solved before. As such, you know how to solve it.
Naturally, the solution to the problem will be a slightly more generalized form that’s applicable to how you’ve previously applied it.
This generalized form of the solution can be considered the design pattern.

The general implementation and architecture will look exactly the same; however, the specifics of the implementation will naturally vary from project-to-project, but that’s simply the nature of the beast.

In the upcoming sections and upcoming articles, we’ll be taking a look at this in a bit more detail.

Design Patterns in WordPress

If you’ve done any type of WordPress development involving the hook system – that is, you’ve written entire plugins, themes, or even a simple function and taken advantage of the add_action or add_filter functions – then you’ve used design patterns.

WordPress uses what’s called an event-driven design pattern. There are several variations of event-driven design patterns one of which we’ll review momentarily, but the gist of the patterns are all the same:

Part of the pattern implements what’s known as a publisher
Part of the pattern implements what’s known as a subscriber

Generally speaking, the publisher broadcasts a message that something has happened to all objects that are subscribed to that particular publisher.

Another way of looking at this is that, in software, whenever something happens we say that an event is raised. Perhaps the most common place we see this in web development is in JavaScript with things such as the mouse being clicked, a key on the keyboard being pressed, or something similar.

We then write functions that handle those functions, and these functions are appropriately referred to as event handlers because they are responsible for handling the case when an event happens.

Not terribly complicated, right? Honestly, sometimes I think the terminology can be more confusing than the actual implementation.

So anyway, in the context of WordPress – or any web application, for that matter – events aren’t limited to key presses or mouse clicks. Instead, it can happen during various parts of the page load lifecycle, when data is written to the database, when data is read to the database, and so on.

Ultimately, you can implement the pattern however you like so that you can provide hooks into which developers can register functions to fire as soon the event occurs.

This brings us full circle back to WordPress’ architecture: Hooks are placed throughout the code such that we’re able to register a function to fire whenever something occurs (that is, whenever an event happens).

A Look at an Event-Driven Architecture: The Observer Pattern

There are a number of event-driven design patterns, one of which is known as the Observer Pattern. This particular pattern is also known as the Publisher-Subscriber Pattern or, more concisely, Pub-Sub.

In the simplest implementation of this pattern, there is a single publisher that is responsible for broadcasting messages to one or many subscribers. The subscribers are responsible for registering themselves with the publisher, and then the publisher is responsible for sending a message or taking action on all of the subscribers.

A high-level diagram would look something like this:

From a code perspective, the Publisher needs three things:

A way to maintain a list of the subscribers
A way for the subscribers to register themselves
A way to broadcast a message to all of the subscribers

Similarly, the Subscriber needs to be able to do two things:

Register itself with the Publisher
Optionally take action when the Publisher sends a message to it

There are a number of ways in which this can be implemented, but for all intents and purposes and to keep the example relatively simple, let’s say that the Subscribers will register themselves with the Publisher with the Observer’s register method and the function accepts a reference to the Subscriber and each Subscriber has an update method that the Publisher calls when broadcasting the message.

Publisher Code

class MyPublisher {

	/** The list of subscribers that are registered with this publisher */
	private $subscribers;

	/**
	 * Responsible for initializing the class and setting up the list of subscribers.
	 */
	public function __construct() {
		$this->subscribers = array();
	} // end constructor

	/**
	 * Adds the incoming subject to the list of registered subscribers
	 *
	 * @param  array  $subject  The subject to add to the list of subscribers
	 */
	public function register( $subject ) {
		array_push( $this->subscribers, $subject );
	} // end register_subscriber

	/**
	 * Notifies all of the subscribers that something has happened by calling their `update`
	 * method.
	 */
	public function notify_subscribers() {

		for ( $i = 0; $l < count( $this->subscribers ); $i++ ) {

			$current_subscriber = $this->subscribers[ $i ];
			$current_subscriber->update();

		} // end for

	} // end notify_subscribers

} // end class

The code above is about as simple as we can make it:

For those who are more experienced with object-oriented techniques, then you’ll likely see the need for creating a class interface for the Publisher, but that’s outside the scope of this particular tutorial.

Remember, the purpose is to simply provide an example of what a simple observer may look like.

Subscribe Code

Creating a Publisher is really only half of the implementation. Remember, we have to have something that actually, you know, subscribes to the Publisher to take action whenever something happens.

This is where the aptly named Subscriber comes into play.

class MySubscriber {

	/** The publisher to which this class registers */
	private $publisher;

	/**
	 * Responsible for initializing the class and setting up a reference to the publisher
	 */
	public function __construct() {

		$this->publisher = new MyPublisher();
		$this->publisher->register( $this );

	} // end constructor

	/**
	 * This is the method that the Publisher calls when it it broadcasts its message.
	 */
	public function update() {

		/** Implementation is based purely on however you'd like. */

	} // end update

} // end class

In short, this is it. Notice above that this implementation of the update function isn’t actually defined. That’s because it gives us the ability to provide unique behavior to this specific instance.

But remember, there’s a lot of code in WordPress core that is not object-oriented. Instead, it’s procedural. As such, the implementation of a pattern like this varies a little bit.

For example, an analogy in WordPress would be something like this:

function my_custom_subscriber( $content ) {

	$content = 'This is my custom content.' . $content;
	return $content;

} // end my_custom_subscriber
add_action( 'the_content', 'my_custom_subscriber' );

Notice that the syntax is a bit different, but we’re essentially doing a very similar thing:

We have a subscribe function – my_custom_subscriber – and it’s registered with the the_content event
When the the_content function fires, our custom function will fire.

Nothing too complicated, I hope.

One of the goals in this series is not only to provide a few examples of design patterns and how to implement them, but they are already in place in existing systems.

The Patterns We’ll Examine

In addition to the event-driven pattern that we’ve examined above, we’re also going to take a look at two patterns that are common, practical, and highly useful in our day-to-day work.

Specifically, we’re going to take a look at the following patterns:

Singleton Pattern. In object-oriented design, the Single Pattern ensures that only a single instance of a class is created. This is useful so that we don’t accidentally create multiple instances maintaining their own sets of data ultimately giving conflicting results during a project’s lifecycle.
Simple Factory Pattern. If you have a collection of classes each of which are designed to handle a specific type of data (as opposed to have one large class do it), then the Simple Factory Pattern is useful for taking a look at the incoming data and then returning an instance of the proper class for processing the data.

Obviously, talking about software only goes so far without talking about diagrams and/or code so we’ll be taking a look at both of those in the upcoming set of articles.

Conclusion

As you can see, the concept of design patterns isn’t anything terribly complicated and there’s a lot to be gained by using them in our work. Perhaps the greatest challenge that developers face is using design patterns for the sake of using design patterns.

Instead, it’s important to recognize that there are certain situations in which design patterns are applicable. That is to say that there are certain problems for which design patterns are the perfect solution. Experience is arguably the best teacher for knowing when to use a design pattern and when not to use it.

In the following articles, hopefully we’ll be able to cover enough territory to provide two solid examples of design patterns, when they’re applicable, how to use them, and how they can help us in our future work.

Learn WordPress Plugin Development with Tuts+ Live Workshops

Joel Bankhead — Thu, 09 May 2013 13:05:08 +0000

We are excited to announce a fantastic new workshop led by Instructor Tom McFarlin: Introduction to WordPress Plugin Development

Tickets are a great investment at $99, but places are strictly limited so act fast to make sure you don’t miss out!

Introduction to WordPress Plugin Development

Learn more about Introduction to WordPress Plugin Development

Workshop Schedule

The weekly workshops will be taking place at 12pm EDT (US), on the following days:

Thursday 30th May – Let’s Set Up
Thursday 6th June – Planning The Plugin
Thursday 13th June – Building WP IS.GD – Part 1
Thursday 20th June – Building WP IS.GD, Part 2
Thursday 27th June – Preparing The Plugin For Release

Sign Up to Our Newsletter

We’re really excited about new workshop, Introduction to WordPress Plugin Development, but places are strictly limited so act fast to make sure you don’t miss out!