Wptuts+

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

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

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 3 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 3 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 3 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.

Introduction to WordPress Plugin Development: Early Bird Tickets Now Available!

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

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

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.

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!

Tuts+ Premium Cash Back Offer: 3 Days to Go

Joel Bankhead — Wed, 08 May 2013 14:00:30 +0000

This offer ends soon! Act now and don’t miss out on cash back when trying a monthly Tuts+ Premium subscription.

At $19 a month, Tuts+ Premium is fantastic value. But it’s even better when we hand your first $19 right back to you!

For a limited time we’re offering $19 cash back to new Tuts+ Premium monthly subscribers when signing up via PayPal. If you’ve been thinking about checking out our extensive library of courses, tutorials, eBooks and guides there’s never been a better time to join up and dive in.

This offer ends at noon on the 20th of May AEST, so act fast.

Become a Tuts+ Premium Member and take your creative & technical skills to a new level.

What can you learn on Tuts+ Premium? Glad you asked! Currently, more than 15,000 members are sharpening their skills in a wide range of areas including web design, web development, Photoshop, vectors, video effects, and many more.

With Tuts+ Premium you learn from expert instructors in every field, such as:

Designer Justin Maller (Nike, Verizon, DC Shoe Co.)
Illustrator Russell Tate (McDonald’s, Coca-Cola)
Developer Burak Guzel (Software Engineer at Facebook)

Join now and get instant access to your very own library of courses, tutorials, and eBooks, available whenever you need them. Become part of a community of over 15,000 members and start getting better at the skills you care about. Our dedicated team adds new content weekly, so there’s always something fresh to sink your teeth into.

Join Tuts+ Premium

Quick Tip: After the Content – More From This Category

Barış Ünver — Tue, 07 May 2013 14:01:34 +0000

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

Do you have a solid construction of categories on your blog? If so, you might not need a “Related Posts” section at all – you can just display latest posts from the same category.

In this post, we’re going to go through the “More From This Category” section, an alternative to “Related Posts” (which we covered earlier).

Show You Have More to Say

If you keep your posts organized well with categories, you might find it useful to have a list of posts from the post’s category.

“Related Posts” is not always the answer: If you have a website where the posts are separated with categories, a “Related Posts” section might “break” this separation.

For example, if you have a blog about different occupational groups, you can’t show news about the textile sector as “Related News” under a post about informatics. A number of latest posts from the same category would be more relevant, right?

Creating a “More From This Category” List

As you may have guessed, listing latest posts from a post’s category will be much easier than displaying related posts based on a post’s tags. We just need to get the category of the post and list a number of posts from that category, excluding the post that the visitors have just read. The arguments that we can pass in the get_posts() function has everything we need.

<?php
// "More from This Category" list by Barış Ünver @ Wptuts+
function wptuts_more_from_cat( $title = "More From This Category:" ) {
    global $post;
    // We should get the first category of the post
    $categories = get_the_category( $post->ID );
    $first_cat = $categories[0]->cat_ID;
    // Let's start the $output by displaying the title and opening the <ul>
    $output = '<div id="more-from-cat"><h3>' . $title . '</h3>';
    // The arguments of the post list!
    $args = array(
        // It should be in the first category of our post:
        'category__in' => array( $first_cat ),
        // Our post should NOT be in the list:
        'post__not_in' => array( $post->ID ),
        // ...And it should fetch 5 posts - you can change this number if you like:
        'posts_per_page' => 5
    );
    // The get_posts() function
    $posts = get_posts( $args );
    if( $posts ) {
		$output .= '<ul>';
		// Let's start the loop!
		foreach( $posts as $post ) {
			setup_postdata( $post );
			$post_title = get_the_title();
			$permalink = get_permalink();
			$output .= '<li><a href="' . $permalink . '" title="' . esc_attr( $post_title ) . '">' . $post_title . '</a></li>';
		}
		$output .= '</ul>';
	} else {
		// If there are no posts, we should return something, too!
		$output .= '<p>Sorry, this category has just one post and you just read it!</p>';
	}
    // Let's close the <div> and return the $output:
    $output .= '</div>';
    return $output;
}
?>

Done! You can include this function inside your functions.php file (or save it as a separate plugin) and echo it (as <?php echo wptuts_more_from_cat( 'More From This Category:' ); ?>) anywhere you want inside your single.php file.

Conclusion

Yes, content may be “king” but a lonely king is a weak king, and people might not respect that “king”.

Do you think there are more page elements that can help “the king”? Post your comments below – it’s always important for you to share your thoughts with us!

A Walkthrough for Jetpack’s “Post by Email” Feature

Barış Ünver — Mon, 06 May 2013 13:15:34 +0000

WordPress has a sufficient, mostly responsive, back-end and great applications for mobile devices, but there might come a day when you’ll just want to send an email to post an entry to your website.

In this post, we’re going to go through this handy little feature of Jetpack: Post by Email.

WordPress has a Post via Email functionality in its core, but it’s far from being handy or user friendly.

As the Codex says, you have to:

Create a dedicated e-mail account to be used solely for posting to your blog
Configure WordPress to access that account via POP3
Configure WordPress to publish messages from that e-mail account

And even if you do, you’re stuck with plain text posts and you can’t post any email attachments!

Plus, you have to at least set up a function in your theme (or as a separate plugin) for WordPress to recognize your email as a post. Oh, did I mention that you can only select one category to post and you can’t set any tags or any other kind of taxonomy?

Luckily, this problematic approach can be replaced with Jetpack, another creation from Automattic. The Post by Email module solves all the problems above and allows you to do lots more. In short, you can:

Use HTML in your email
Include attachments (and include the attached images as a slideshow or an inline gallery)
Set a title (and a slug) different than your email title
Set categories and tags
Turn on or off comments for the post
Set an excerpt
Change the status of the post
Set a password for the post
Set a time for the post to be published
Add <--more--> and <--nextpage--> tags inside the post
End your post anywhere inside your email
Include a PollDaddy poll
Turn off geotagging
Set Publicize options, another module of Jetpack

Warming Up

You need to do a bunch of things with Jetpack, too:

Install the plugin
Connect your website with your WordPress.com account
Check if the “Post by Email” module is enabled
Go to Users » Your Profile and click on “Enable Post by Email”
Get the special email address and add it to your address book

Notice that you don’t even have to use your keyboard while taking these steps – except, maybe, entering your WordPress.com credentials. After doing these in order, you’re ready to send your first post via email!

Available Shortcodes

Now that you’re all set on your WordPress admin panel, you can now log in to your email account – the one you’re registered with WordPress.com. With your first post (and all others, naturally), you can use the following shortcodes anywhere inside your email:

Title: `[title Hello World!]`

Parameters: The specified title.

If you want to send an email with a different title than the title of the post, you can use this shortcode to set a title for the post. If this shortcode is used, Jetpack will disregard the title of the email.

Slug: `[slug oh-hai]`

Parameters: The specified slug.

The usual “slug”, the words on the address bar. You can use this shortcode to use shorter URLS like myblog.com/hawaii-trip/ and avoid huge ones like myblog.com/a-trip-to-hawaii-what-i-expected-to-see-and-what-i-saw/.

Categories: `[category News, Personal]`

Parameters: Comma separated category names or IDs.

You can set any category you want with this shortcode. Just use names or IDs as parameters and you’re good to go! It even gets the right category when you don’t use the full name, like “Anno” instead of “Announcements”.

Tags: `[tags lorem, ipsum, dolor]`

Parameters: Comma separated tag names.

Like categories, you can use tag names

P.S. As far as I can see, it doesn’t support custom taxonomies, which is a bummer. It would be great if a [tax] shortcode is introduced and used like this: [tax custom-taxonomy]lorem, ipsum, dolor[/tax] (where the default parameter is “tag”). Let’s hope the module will support this in the future :).

Comments: `[comments off]`

Parameters: “on” or “off”.

No need to explain this one: You can turn on or off comments on your post with this shortcode.

Post Status: `[status private]`

Parameters: “publish” (default), “private”, “pending” or “draft”.

Again, this is self-explanatory: You can set the four parameters to set the status of your post.

Post Password: `[password CorrectHorseBatteryStaple]`

Parameters: The specified password.

You can protect your post with a password with this shortcode.

P.S. I got the password from an XKCD comic.

Publish Date/Time: `[delay +2 days]`

Parameters: a date/time description like “+1 week 2 days 3 hours” or “next Saturday” or “25 November 2013″.

Using the strtotime format, you can set the date and time of your post. If you set the parameter to “+2 hours”, your post will be published 2 hours after you send the email.

Excerpt: `[excerpt]...[/excerpt]`

If you’re using the “excerpts” of WordPress posts on your website, you can set an excerpt between [excerpt] and [/excerpt] tags.

Geotagging: `[geotag off]`

Parameters: “on” or “off”.

If your phone (or email client) is using your GPS information inside the emails, geotagging will be enabled by default. If you don’t want to share that information on your posts, you should disable it by using this shortcode with the parameter “off”.

Publicize: `[publicize facebook twitter]`

Parameters: Space separated list of services (like Facebook and Twitter) or “off”.

Jetpack has another useful module called Publicize, letting you share your post automatically on social networks when it’s published. If you want to do the same with email, you can use this shortcode to Publicize your post.

Separating Content: `[more]` and `[nextpage]`

These two are also self-explanatory: If you ever need to use the <--more--> or <--nextpage--> tags inside your post, you can use these shortcodes.

Attachments: `[slideshow]` and `[noslider]`

By default, Jetpack will include your image attachments in the post. If you attach just one image, it will be displayed inline and if you attach more, all of them will form a gallery.

If you don’t like this behavior, you can use [nogallery] to display all images inline or use [slideshow] to replace the gallery with a slideshow.

PollDaddy Polls: `[poll]`

Parameters: “type” (single, multi or a number), “style” (manga or medium), “other” (yes or no).

If you have a PollDaddy account, you can use this shortcode to include a poll inside your post. Here’s an example on how to use it:

[poll type="3" style="medium" other="yes"]
What are your favorite Tuts+ blogs? (select three)
* Wptuts+
* Nettuts+
* Webdesigntuts+
* Psdtuts+
* Phototuts+
[/poll]

The End: `[end]`

There could be email signatures you can’t remove (company policy, hmpfh) or your smartphone could add lines like “sent from myPhone” (that company‘s policy, hmpfh) and you wouldn’t want these signatures to be included in your post.

Jetpack automatically cuts out the text after a signature block or an <hr /> tag, but you can use [end] alternatively to end the post right where you use it.

Wrapping Up

I always thought that the core “post via email” feature of WordPress was too much limiting, kind of redundant and absolutely hard to use. Now that we went through everything Jetpack’s “Post by Email” module can do, I’m glad that there’s an alternative to it, also developed by Automattic.

What do you think about this feature – do you plan to use it? Share your comments below and don’t forget to share the post!

Guide to Creating Your Own WordPress Editor Buttons

Lee Pham — Tue, 30 Apr 2013 14:20:14 +0000

Most likely you know that WordPress is bundled with the HTML WYSIWYG editor, TinyMCE. The variety of features, and the ability to be extended though plugins, make it the most used WYSIWYG editor in the world. WordPress doesn’t make use of all its features, however. WordPress customizes it and only keeps parts which are really helpful to users, avoiding messing up the user interface. That also means some features, buttons for example, have been hidden from users. You can totally enable the hidden MCE buttons. Typically they are stylesheet, sub, sup buttons. If even the hidden ones still don’t satisfy your needs, then you have to create a TinyMCE plugin to do add your own. In this tutorial, I will walk you through the basics of adding your WordPress Editor buttons by creating a TinyMCE plugin.

Before We Start

As mentioned earlier, we will create a new TinyMCE plugin whose task is to add the new buttons we want. So which buttons are we going to add? We will try to add two simple buttons: Dropcap and Recent Posts, in which the former gives you the ability to convert a selected letter to a drop cap letter, and the latter will display recent posts. The code generates these buttons shown below.

Let’s create a new folder named wptuts-editor-buttons (of course, you can change it to something else if you want) in your theme directory (I’m using TwentyTwelve). Continue to create two new files, wptuts.php that invokes customized PHP, and the other named wptuts-plugin.js where the JavaScript code snippets will be located. Finally, open your theme’s functions.php file and include the newly created wptuts.php file in it. Note, remember to define its path exactly:

require( 'wptuts-editor-buttons/wptuts.php' );

Then we need to prepare some code for those two buttons:

Dropcap – The ideal way of making a letter into drop caps is to simply wrap the user’s selected letter within a pre-defined HTML span class which styles that letter to look like drop caps. The CSS code of the class shown below, just appends it to your theme’s style.css file:
```
		/* Add this code in style.css */
		.dropcap {
			float: left;
			font-size: 80px;
			padding-right: 7px;
			line-height: 72px;
		}
		
```

Recent Posts – We will make a shortcode that will add a list of recent posts into the page, open the wptuts.php file and add the following code:

		add_shortcode( 'recent-posts', 'wptuts_recent_posts' );
		function wptuts_recent_posts( $atts ) {
			extract( shortcode_atts( array(
				'numbers' => '5',
			), $atts ) );
			$rposts = new WP_Query( array( 'posts_per_page' => $numbers, 'orderby' => 'date' ) );
			if ( $rposts->have_posts() ) {
				$html = '<h3>Recent Posts</h3><ul class="recent-posts">';
				while( $rposts->have_posts() ) {
					$rposts->the_post();
					$html .= sprintf(
						'<li><a href="%s" title="%s">%s</a></li>',
						get_permalink($rposts->post->ID),
						get_the_title(),
						get_the_title()
					);
				}
				$html .= '</ul>';
			}
			wp_reset_query();
			return $html;
		}

We assume that when users click the Recent Posts button, the browser will popup a dialog asking them for the number of posts they want to show. After having that number, the editor will fill it as an argument into the above shortcode. For example, if we want to show seven recent posts, the shortcode is generated as follows:

		[recent-posts numbers="7"/]

Registering a New TinyMCE Plugin

Assuming we already had the new plugin, then we need to register it with WordPress to integrate it into the TinyMCE editor. The code is shown below:

add_action( 'init', 'wptuts_buttons' );
function wptuts_buttons() {
	add_filter( "mce_external_plugins", "wptuts_add_buttons" );
	add_filter( 'mce_buttons', 'wptuts_register_buttons' );
}
function wptuts_add_buttons( $plugin_array ) {
	$plugin_array['wptuts'] = get_template_directory_uri() . '/wptuts-editor-buttons/wptuts-plugin.js';
	return $plugin_array;
}
function wptuts_register_buttons( $buttons ) {
	array_push( $buttons, 'dropcap', 'showrecent' ); // dropcap', 'recentposts
	return $buttons;
}

The important filter hook mce_external_plugins is used to hook the new plugin to TinyMCE. We need to pass a plugin ID (wptuts) and the absolute URL pointing to our wptuts-plugin.js file. The mce_buttons hook is used to tell the TinyMCE editor which buttons in our plugin we want to show. The dropcap and showrecent are the ID values of these buttons that we plan to create. Keep in mind these values, they will be used later.

Setting Up TinyMCE Plugin

In general, I think the best way to extend or develop something on a platform is to consult the documentation for that platform. TinyMCE has its own wiki that you might find useful. By following an example of how to create a TinyMCE plugin, we have the following initialisation code:

(function() {
	tinymce.create('tinymce.plugins.Wptuts', {
		/**
		 * Initializes the plugin, this will be executed after the plugin has been created.
		 * This call is done before the editor instance has finished it's initialization so use the onInit event
		 * of the editor instance to intercept that event.
		 *
		 * @param {tinymce.Editor} ed Editor instance that the plugin is initialized in.
		 * @param {string} url Absolute URL to where the plugin is located.
		 */
		init : function(ed, url) {

		},

		/**
		 * Creates control instances based in the incomming name. This method is normally not
		 * needed since the addButton method of the tinymce.Editor class is a more easy way of adding buttons
		 * but you sometimes need to create more complex controls like listboxes, split buttons etc then this
		 * method can be used to create those.
		 *
		 * @param {String} n Name of the control to create.
		 * @param {tinymce.ControlManager} cm Control manager to use inorder to create new control.
		 * @return {tinymce.ui.Control} New control instance or null if no control was created.
		 */
		createControl : function(n, cm) {
			return null;
		},

		/**
		 * Returns information about the plugin as a name/value array.
		 * The current keys are longname, author, authorurl, infourl and version.
		 *
		 * @return {Object} Name/value array containing information about the plugin.
		 */
		getInfo : function() {
			return {
				longname : 'Wptuts Buttons',
				author : 'Lee',
				authorurl : 'http://wp.tutsplus.com/author/leepham',
				infourl : 'http://wiki.moxiecode.com/index.php/TinyMCE:Plugins/example',
				version : "0.1"
			};
		}
	});

	// Register plugin
	tinymce.PluginManager.add( 'wptuts', tinymce.plugins.Wptuts );
})();

Remember to add this code into the wptuts-plugin.js file. We’ve left the code comments for you to easily understand what’s going on. The above code just does two main tasks:

First, defining a new TinyMCE plugin in a safe way by calling TinyMCE’s create method. Our plugin’s behavior will be defined in the init and createControl functions. You can see that the plugin’s information is declared in the getInfo function too. Our plugin will have the name Wptuts and the ID wptuts as you can see.
Last, simply add our new plugin into the TinyMCE Plugin Manager.

Creating Buttons

In the init function, we start to create our buttons. The code seen as follows:

(function() {
	tinymce.create('tinymce.plugins.Wptuts', {
		init : function(ed, url) {
			ed.addButton('dropcap', {
				title : 'DropCap',
				cmd : 'dropcap',
				image : url + '/dropcap.jpg'
			});

			ed.addButton('showrecent', {
				title : 'Add recent posts shortcode',
				cmd : 'showrecent',
				image : url + '/recent.jpg'
			});
		},
		// ... Hidden code
	});
	// Register plugin
	tinymce.PluginManager.add( 'wptuts', tinymce.plugins.Wptuts );
})();

By using the addButton method of the ed object, we tell the current editor that we want to create all these buttons. This method accepts two arguments:

The first one is the button’s ID. In the previous section, we mentioned it. It must be the same as the one we defined before. Otherwise, it will not work properly.
The second one is the object containing the button’s information, such as:
- The button’s title
- The most important: the task that the button will do. Take a look at the cmd property, it has the value of showrecent. That is the command’s ID which is executed every time it is called, we will go into detail shortly
- The image of the button. Note that the URL parameter holds the absolute directory’s URL in which our plugin is located, this makes it easier to reference the image that you want. So you need to place your image into the plugin’s folder and ensure its name to is set precisely to the image‘s value.

Now, check the WordPress editor and we will see our buttons showing up. However, they do nothing right now.

Our buttons showed up.

Adding Buttons’ Commands

We’ve defined the name of the commands our buttons will execute, but have not yet defined what they will actually run. In this step, we will set up the things our buttons will do. Inside the init function, continue to add this code as shown:

(function() {
	tinymce.create('tinymce.plugins.Wptuts', {
		init : function(ed, url) {
			ed.addButton('dropcap', {
				title : 'DropCap',
				cmd : 'dropcap',
				image : url + '/dropcap.jpg'
			});

			ed.addButton('showrecent', {
				title : 'Add recent posts shortcode',
				cmd : 'showrecent',
				image : url + '/recent.jpg'
			});

			ed.addCommand('dropcap', function() {
				var selected_text = ed.selection.getContent();
				var return_text = '';
				return_text = '<span class="dropcap">' + selected_text + '</span>';
				ed.execCommand('mceInsertContent', 0, return_text);
			});

			ed.addCommand('showrecent', function() {
				var number = prompt("How many posts you want to show ? "),
					shortcode;
				if (number !== null) {
					number = parseInt(number);
					if (number > 0 && number <= 20) {
						shortcode = '[recent-post number="' + number + '"/]';
						ed.execCommand('mceInsertContent', 0, shortcode);
					}
					else {
						alert("The number value is invalid. It should be from 0 to 20.");
					}
				}
			});
		},
		// ... Hidden code
	});
	// Register plugin
	tinymce.PluginManager.add( 'wptuts', tinymce.plugins.Wptuts );
})();

Now, the ed.addCommand method will help us to add a new command. You need to pass the command’s ID and the callback function that will be executed if it was called by the ed.execCommand method. Note that ed represents the tinyMCE.activeEditor object. Let’s take a look at the callback functions:

In the dropcap command, the desire we want is when a user selects a letter and clicks the DropCap button, the letter will then be transformed to drop cap form. So how do we get that letter? Well, the ed.selection.getContent method will do that for us. Next, once we’ve gotten that letter we just wrap it within a span element. Remember to set this element’s class value to dropcap that we’ve defined before, right? Finally, we have the complete text that needs to be inserted back into the editor. TinyMCE has a default command with the name mceInsertContent which is used to insert specific content into the editor, how to use it is shown above. The content will be passed as the third argument of the mceInsertContent method.
A similar thing happens in the showrecent command as in the dropcap command, excepting we don’t need to get the user’s selected content. We just simply display a dialog asking the user how many posts they want to show up, then insert that number value in an appropriate shortcode syntax.

Registering Custom CSS for Buttons (Optionally)

Instead of adding pure text when the buttons insert contents into the visual editor, we can make it much more visual by registering custom CSS for our buttons. It depends on which type of content data, and you can choose an appropriate style. For example, our Dropcap‘s style can have the same as the one showing on the front-end. So you can take its CSS code in the very top of this post, then place it into the editor-style.css file (for default, see add_editor_style for detais).

For shortcodes, they might not have an HTML element themselves. How should we style them? Well, this situation is much more complex to achieve the result, it’s not impossible though (you can see some default WordPress button such as ‘Add media’). However, it can still be a tricky, by wrapping that shortcode in a HTML element and then styling that element just like above. It’s quite simple, not completely perfect though. In this post, we won’t focus on that complex processing.

Results

Finally, the results we get are shown as following:

Test the Dropcap button.

Then, on the front-end:

Dropcap letter in front-end.

And the Recent Posts button works well too:

Conclusion

Okay, we covered a practice which is quite simple and easy to follow. You might notice that the Recent Posts button allows you to adjust a setting (the number of posts that will show). You certainly know that we used the default JavaScript, prompt, to achieve that. What if you want a more complex popup, which has many settings rather than only one? Well, in another post we will discuss this and try another approach.

Any feedback about this post will be appreciated. Thanks for reading, and see you later.

Wptuts+

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

Introduction to WordPress Plugin Development

Grab an Early Bird Ticket Now!

Design Patterns in WordPress: The Simple Factory Pattern

The Factory Method Pattern

A Note About the Simple Factory Pattern

So Why Does This Matter in WordPress?

What It Looks Like

The Purpose of the Simple Factory

A Look at the Pattern

A Working Example

The Plugin

The User

The Administrator, The Reader, and The Volunteer

The Administrator

The Reader

The Volunteer

The Simple Factory

The Advantages of the Simple Factory Pattern

Conclusion

Quick Tip: After the Content – Share This

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

Plugins to Offer a “Share This” Section

Conclusion

Design Patterns in WordPress: The Singleton Pattern

The Singleton Pattern

So Why Does This Matter in WordPress?

What It Looks Like

The Advantages of the Singleton Pattern

Conclusion

Design Patterns in WordPress: An Introduction

Design Patterns Defined

Design Patterns in WordPress

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

Publisher Code

Subscribe Code

The Patterns We’ll Examine

Conclusion

Introduction to WordPress Plugin Development: Early Bird Tickets Now Available!

Introduction to WordPress Plugin Development

Grab an Early Bird Ticket Now!

Tuts+ Premium Cash Back Offer: 3 Days to Go

Quick Tip: After the Content – More From This Category

Show You Have More to Say

Creating a “More From This Category” List

Conclusion

A Walkthrough for Jetpack’s “Post by Email” Feature

Warming Up

Available Shortcodes

Title: [title Hello World!]

Slug: [slug oh-hai]

Categories: [category News, Personal]

Tags: [tags lorem, ipsum, dolor]

Comments: [comments off]

Post Status: [status private]

Post Password: [password CorrectHorseBatteryStaple]

Publish Date/Time: [delay +2 days]

Excerpt: [excerpt]...[/excerpt]

Geotagging: [geotag off]

Publicize: [publicize facebook twitter]

Separating Content: [more] and [nextpage]

Attachments: [slideshow] and [noslider]

PollDaddy Polls: [poll]

The End: [end]

Wrapping Up

Guide to Creating Your Own WordPress Editor Buttons

Before We Start

Registering a New TinyMCE Plugin

Setting Up TinyMCE Plugin

Creating Buttons

Adding Buttons’ Commands

Registering Custom CSS for Buttons (Optionally)

Results

Conclusion

Reference

Title: `[title Hello World!]`

Slug: `[slug oh-hai]`

Categories: `[category News, Personal]`

Tags: `[tags lorem, ipsum, dolor]`

Comments: `[comments off]`

Post Status: `[status private]`

Post Password: `[password CorrectHorseBatteryStaple]`

Publish Date/Time: `[delay +2 days]`

Excerpt: `[excerpt]...[/excerpt]`

Geotagging: `[geotag off]`

Publicize: `[publicize facebook twitter]`

Separating Content: `[more]` and `[nextpage]`

Attachments: `[slideshow]` and `[noslider]`

PollDaddy Polls: `[poll]`

The End: `[end]`