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 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.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/LiE2W9rPjEo/
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.
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.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/9OSVpqV7FhY/
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!
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.
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!
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!
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.
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!
When it comes to creating a Custom Post Type within a WordPress plugin, there’s always the same problem: you need to create a custom single-[cpt_slug].php file in your theme folder if you don’t want to use the default single.php file from your theme.
In this post I’d like to cover two aspects of using custom templates. The first step is to show that we can use a custom file contained directly in the plugin itself instead of loading the default single.php, and the second one is how to create your own custom file in your theme folder.
Many plugins like Easy Digital Downloads or Shopp, use this method: the plugin checks if you define a custom template in your theme folder, if it is the case then the file is loaded, otherwise the default plugin template file is loaded. In both cases the theme default single.php file isn’t loaded.
/>
Define the Plugin and Its Structure
The very first step is to create a plugin, let’s call it “Template Chooser“. Create a “template-chooser” folder under /wp-content/plugins/, with the following structure:
The plugin structure
Then open the main file template-choose.php and place the following plugin header code:
/*
Plugin Name: CPT template Chooser
Plugin URL: http://wp.tutsplus.com/
Description: Loads a custom template file instead of the default single.php
Version: 0.1
Author: Remi Corson
Author URI: http://wp.tutsplus.com/
*/
/>
Define the Plugin Constants
Later in the plugin we will need to easily retrieve the plugin URL and its path, that’s why we need to define a few constants:
To go further, we have to setup a new custom post type, let’s create a “Testimonial” CPT, with some very basic supports and features. As the aim of the post is not to teach how to create a custom post type, I’ll use a pretty simple code divided in 3 parts: the custom post type labels, the supports, and the custom post type arguments. All that embed in a single function:
/*
|--------------------------------------------------------------------------
| DEFINE THE CUSTOM POST TYPE
|--------------------------------------------------------------------------
*/
/**
* Setup testimonial Custom Post Type
*
* @since 1.0
*/
function rc_tc_setup_post_types()
// Custom Post Type Labels
$labels = array(
'name' => esc_html__( 'Testimonials', 'rc_tc' ),
'singular_name' => esc_html__( 'Testimonial', 'rc_tc' ),
'add_new' => esc_html__( 'Add New', 'rc_tc' ),
'add_new_item' => esc_html__( 'Add New Testimonial', 'rc_tc' ),
'edit_item' => esc_html__( 'Edit Testimonial', 'rc_tc' ),
'new_item' => esc_html__( 'New Testimonial', 'rc_tc' ),
'view_item' => esc_html__( 'View Testimonial', 'rc_tc' ),
'search_items' => esc_html__( 'Search Testimonial', 'rc_tc' ),
'not_found' => esc_html__( 'No testimonial found', 'rc_tc' ),
'not_found_in_trash' => esc_html__( 'No testimonial found in trash', 'rc_tc' ),
'parent_item_colon' => ''
);
// Supports
$supports = array( 'title', 'editor' );
// Custom Post Type Supports
$args = array(
'labels' => $labels,
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'query_var' => true,
'can_export' => true,
'rewrite' => array( 'slug' => 'testimonials', 'with_front' => true ),
'capability_type' => 'post',
'hierarchical' => false,
'menu_position' => 25,
'supports' => $supports,
'menu_icon' => RC_TC_PLUGIN_URL . '/includes/images/testimonials_icon.png', // you can set your own icon here
);
// Finally register the "testimonial" custom post type
register_post_type( 'testimonial' , $args );
add_action( 'init', 'rc_tc_setup_post_types' );
/>
Do Not Use the Default single.php File
Now that our custom post type is registered, we need to create a function that will tell WordPress not to use the default single.php from the theme.
Because yes by default when displaying a custom post type on the frontend WordPress will check if a file called single-testimonial.php exists and will load it. If not, it will look for the single.php. But we don’t want to use any of them.
We want WordPress to load a custom file from the plugin. To do so, we have to hook a new function to the “template_include” filter. In this function the aim is to check the type of the post and act in consequence:
/*
|--------------------------------------------------------------------------
| FILTERS
|--------------------------------------------------------------------------
*/
add_filter( 'template_include', 'rc_tc_template_chooser');
/*
|--------------------------------------------------------------------------
| PLUGIN FUNCTIONS
|--------------------------------------------------------------------------
*/
/**
* Returns template file
*
* @since 1.0
*/
function rc_tc_template_chooser( $template )
// Post ID
$post_id = get_the_ID();
// For all other CPT
if ( get_post_type( $post_id ) != 'testimonial' )
return $template;
// Else use custom template
if ( is_single() )
return rc_tc_get_template_hierarchy( 'single' );
}
/>
Load the Right Template
As you can see, on line 33 we are calling a new function rc_tc_get_template_hierarchy(). This is the function that will check if WordPress has to load the custom file from the plugin or the template from the theme folder.
Please note that when I’m talking about the “template from the theme folder”, I’m talking about a custom file loaded instead of the single.php.
Let’s say you don’t want to load the template included in the plugin but create your own custom template, all you have to do is to create a new folder in the theme folder, name it “plugin_template” and within this folder create a single.php file. This will be your new default single.php loaded only for testimonials displayed on the frontend.
Are you still with me? Okay, so let’s create the function:
/**
* Get the custom template if is set
*
* @since 1.0
*/
function rc_tc_get_template_hierarchy( $template )
// Get the template slug
$template_slug = rtrim( $template, '.php' );
$template = $template_slug . '.php';
// Check if a custom template exists in the theme folder, if not, load the plugin template file
if ( $theme_file = locate_template( array( 'plugin_template/' . $template ) ) )
$file = $theme_file;
else
$file = RC_TC_BASE_DIR . '/includes/templates/' . $template;
return apply_filters( 'rc_repl_template_' . $template, $file );
}
/*
|--------------------------------------------------------------------------
| FILTERS
|--------------------------------------------------------------------------
*/
add_filter( 'template_include', 'rc_tc_template_chooser' );
/>
The Plugin Default Template
Now create a new testimonial in the administration. Then open includes/templates/single.php and then copy and paste this simple code:
we are in the plugin custom file
If you visualize the testimonial on the frontend you should see the “we are in the plugin custom file”. That’s what we wanted. But if the plugin template file doesn’t fit your needs or if you simply want to create a more personal design, you can create a file in your theme folder.
/>
The Theme Default Template
To create a custom template that does not use the default one from the plugin, you can create a new folder called “plugin_templates” in your theme folder. Create a new file called single.php and place this code:
we are in the theme custom file
/>
Conclusion
So what did we do exactly? Well, we created a plugin that registers a custom post type “Testimonial“. We achieved functionality to load a custom file stored in the plugin folder instead of the default single.php or single-testimonial.php files from the theme folder. We also managed to load a custom file instead from the theme folder located under “plugin_templates“.
Why is this nice? Because when you create your own plugin you can provide a default template to display the custom post type so you’re giving the choice to the final user whether to use their own template or not.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/fJrspDqkPQU/
Everyone these days tries to rank their site’s content higher in Google Search results. There are marketing firms earning a good deal of revenue in relation to the most notorious digital term these days, “SEO”. In this post I will be explaining the different aspects of “On Page SEO”, how to deal with it in WordPress using one of the best free plugins: WordPress SEO by Yoast.
This is a series of tutorials, in the first one we will be configuring and understanding different sections of the WordPress SEO Plugin. Future tutorials in this series will be about different aspects of SEO, how to utilize your site’s Tags & Categories, the concept of rel='canonical', a practical example of an SEO optimized post, and finally some discussion about what else you need to do after having this plugin configured.
/>
/>
Our Goals
This tutorial will help you in optimizing your WordPress sites with the most popular aspects of On Page SEO. Today our goal is to configure this WordPress SEO plugin and to understand the meaning of each step.
Search engine optimization (SEO) is the process of affecting the visibility of a website or a web page in a search engine’s “natural” or un-paid (“organic”) search results. In general, the earlier (or higher ranked on the search results page), and more frequently a site appears in the search results list, the more visitors it will receive from the search engine’s users.
Why the plugin WordPress SEO By Yoast? I believe it is the best and most complete SEO plugin available for free, though not as easy as AIO SEO, but it comprises of certain vital SEO modules which are the results of the vast experience of Joost de Valk – An elite WordPress developer who developed this plugin.
/>
Dashboard
First of all head over to your WordPress admin panel and install the plugin named WordPress SEO by Yoast (Go to Plugins > Add New > Search for WordPress SEO By Yoast > Install it > Then activate it). After activating the plugin, if you observe the left side menu, you will find a new panel introduced with the name SEO, just like the one in the image below.
When you click it you will be inside the Dashboard of the WordPress SEO plugin. Here you can take a tour or restore the default settings of this plugin in future. More over you will find Tracking and Security check boxes.
Tracking
It allows the author of the plugin to track issues with the plugin if there are any, in future. If you are concerned about your privacy you should keep it unchecked.
Security
This option, if checked, will disallow your Editors and Authors from redirecting a post to another URL, which is one of the capabilities of the plugin. Checking this will also forbid them from no-indexing your posts. If you don’t trust your Editors and Authors, this option should be checked.
Webmaster Tools
These tools allow you to easily verify your site’s ownership by using the meta code provided by Google and Bing Webmaster tools. This option can also help you in verifying your site for Alexa (if you have their premium subscription). You can see I have filled in the Google Webmaster’s meta code.
Tip: Using Google & Bing Webmaster tools help you in understanding the behavior of your site (how much your site is linked, 404 errors, page speed etc).
After you are done with these configurations you can press the button saying “Save Settings“.
/>
Titles & Metas
Then comes the Titles and Metas panel, this panel helps you in configuring the title, site wide metas, and cleaning up the head. Let’s see what the options are here and how to deal with them:
Force Rewrite Titles
This option means that the WordPress SEO plugin needs to change the title tag of your installed theme, so that it can modify it as per your settings. This option should normally be ticked.
Site Wide Meta Settings
No-index subpages of archives: It should be checked as it helps your homepage to retain its importance, your Homepage is one of the most important parts of your blog.
Use meta keywords tag: I prefer to check it, as the Search Engines like Yahoo and Bing are known to give some importance to these meta keywords. These are the keywords around which your article is based.
Add noodp meta robots tag sitewide and Add noydir meta robots tag sitewide are used if your site is present in DMOZ or Yahoo Directory, sometimes Google prefers the description of your site from these directories, enabling these tags can help you remove this kind of error.
Clean Up the
There is a theory that Google prefers a clean head. Most of the SEO Analysts suggest to keep your site’s head portion clean, the top most links which the Google bot reads get more importance. I don’t prefer hiding these links, as in RSD, WLW Manifest Links and shortlinks of your WordPress posts are helpful in a way like if you use Microsoft Live Editor to Publish your posts then hiding these links is not preferred. If you plan to clean up the head of your blog anyway, I would recommend you check the first three options and leave the RSS links option unchecked. Why? Because RSS links are read by certain plugins and can get you more subscribers. Some people say these RSS links are valuable assets for your blog. Enough said!
Done with Title and Metas? Press “Save Settings”
/>
Homepage Settings
Click the Home tab inside the plugin and you will land on the page where all the settings of your Homepage can be found. These settings are kind of ‘set and forget’ settings. You can see the character limits in the image below, fill according to your domain name and niche.
Title: 70 Characters, can be Domain Name with Slogan. e.g. TheBookShop.com – Buy Books at Cheapest Rates
Description: 160 characters in which you will use your focused keyword once. e.g. If your site is for a book shop, you can include the term Buy Books here.
Meta keywords: Don’t spam this box, just put 5 to 6 keywords here, and you should put long tail keywords here, e.g. Download Books at Cheap Rates, Cheap priced Books Downloads etc.
After that, go to your profile page from the top right corner of the Admin Bar, fill in the Google+ URL of your profile and select your name from the users list at the Home Tab of the WordPress SEO plugin, so that your thumbnail is displayed with the exact domain name in Google’s Search. It is due to the rel="author" attribute that WordPress SEO adds this to the header with your profile link. This helps you get a good deal of exposure and more clicks. Make a Google+ page for your blog and add the URL in the box at the end, so that rel="publisher" can be added. These two rel attributes are important for your On Page SEO, and help your site rank better.
After all these settings you need to click “Save Settings”.
/>
Post Types
Then click the Post Types tab where you will generically configure the On Page SEO elements for Posts, Pages and Media files.
Posts SEO
The Help tab provides the details about these generic tags we are using here, but I recommend you do it the way it is done in the image below. Why? After experimenting for about three to five years, I have found these settings best. Of course, we are not going to no-index the posts, but if you tick the Meta Robots No-index then search engines won’t index your posts. Either you check the date snippet or not, if your theme supports the date tag then Google will include it in its search results. I find the date factor very important in On Page SEO, though you can find contrary suggestions about this factor from a lot of people.
%% Replaced with the title of the post/page.
%%focuskw%% Replaced with the post’s focus keyword.
%%tag%% Replaced with the current tag/tags.
%%category%% Replaced with the post categories (comma-separated).
% This entry is part 1 of 1 in the series The Beginner's Guide to WordPress SEO by Yoast Everyone these days tries to rank their site’s content higher in Google Search results. There are marketing firms earning a good deal of revenue in relation to the most notorious digital term these days, “SEO”. % Replaced with the post/page excerpt (or auto-generated if it does not exist).
Pages SEO
Set the pages’ parameters as mentioned in the following image:
%%sitename%% The site’s name
Media SEO
If you want to index media files separately then you can uncheck the checked box against Meta Robots, and set it like the below image:
/>
Taxonomies
The WordPress SEO plugin allows you to configure the On Page SEO parameters for taxonomies like Categories, Tags, Formats and any Custom Taxonomies, if you have them.
Categories VS Tags
Normally Categories are used to categorize the content into organized form, and tags are used to put more aliases for a single post. Right now our focus is towards the configuration of WordPress SEO by Yoast, so we will skip this discussion, but you will read some details about this in next tutorial of the series.
What to Do?
I don’t index both of them so that Search Engines should give most importance to my main article’s titles instead of Tags or their Categories. Here are the settings, if you see I have checked Meta Robots Nofollow so that the Google bot never indexes them.
Formats
Same goes for formats, I have checked no-index for them, you can index them if you want.
Author Archives
It is a matter of your choice, you can index them if you want or else no-index them, Joost de Valk the developer of this plugin has explained it below the options very well.
Date Archives
I recommend you no-index as shown below, you should disable them to save yourself from a Content Duplication penalty.
Other Special Pages
Search and 404 pages can have the following template settings:
/>
That’s All for Now…
In the next tutorial we will configure the Social part, XML Sitemaps, Permalinks, Internal links, RSS, and will look into the robots.txt file. Do you have any questions regarding this tutorial? Let us know.
P.S. I tried my best to be as generic in approach as I could. You can find a lot of contradictory opinions about what I discussed, so to be clear once again, this is how I do things at my side, and I have been working with gigantic blogs and vast networks, these settings and configurations have proven to be great in my experience.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/sOqBQ_522js/
We all love a celebration, and now that Easter is over, we look forward to the next occasion. How far away is the next occasion you like to celebrate? Whatever it might be, let’s build a widget plugin to add a countdown timer to our sidebar showing how long we have left to wait.
/>
1. Getting a Head Start
There are a number of things we need to do every time we’re developing a WordPress plugin, and even more specifically, a widget. Thanks to one of our authors here at Wptuts+, Tom McFarlin, we can get underway quickly by using the WordPress Widget Boilerplate.
To use the WordPress Widget Boilerplate, download it, unzip it, and move the directory widget-boilerplate into your /wp-content/plugins/ directory. Then rename it wptuts-countdowner.
Inside that directory you’ll find the main PHP file, plugin.php, which we’ll also rename to wptuts-countdowner.php.
Now we’re ready to get into the code.
/>
2. Re-Badging the Boilerplate
Inside the wptuts-countdowner.php file is all the heavy lifting done for us by the boilerplate. To begin with, we just need to customise it to reflect the name of our plugin. Then once we’ve written our own code, we can also ditch the extra bits of the boilerplate that we may not need.
The plugin header information will look like this:
So fix that up with the details of our plugin:
We’ll also need to change a few references throughout the boilerplate code to change the generic references to use our plugin name. Most of the places where you’ll need to do this are indicated with a ‘TODO‘.
Find and replace ‘widget-name‘ with ‘wptuts-countdowner‘, and also ‘Widget_name‘ with ‘Wptuts_Countdowner‘. Now the plugin has its own name!
Now you have a plugin you can activate in your WordPress Dashboard. Once activated, when you look under Appearance -> Widgets, you’ll see the beginnings of our widget:
/>
As you can see, it looks pretty generic at the moment. So update the following code:
// TODO: update classname and description
// TODO: replace 'wptuts-countdowner-locale' to be named more plugin specific. Other instances exist throughout the code, too.
parent::__construct(
'wptuts-countdowner-id',
__( 'Widget Name', 'wptuts-countdowner-locale' ),
array(
'classname' => 'wptuts-countdowner-class',
'description' => __( 'Short description of the widget goes here.', 'wptuts-countdowner-locale' )
)
);
To reflect the name and description of our widget:
// TODO: update classname and description
// TODO: replace 'wptuts-countdowner-locale' to be named more plugin specific. Other instances exist throughout the code, too.
parent::__construct(
'wptuts-countdowner-id',
__( 'Wptuts+ Countdowner', 'wptuts-countdowner-locale' ),
array(
'classname' => 'wptuts-countdowner-class',
'description' => __( "A widget to display a countdown timer in your site's sidebar.", 'wptuts-countdowner-locale' )
)
);
Now we have this:
/>
/>
3. Collect Info From the User
Our widget is going to need a name and date for the event to count down (or up) to.
So, we need to create a form to be used when our widget is added to a sidebar for configuration. The WordPress Widget Boilerplate separates the HTML portion into view files for a nice, clean separation of concerns. We’ll setup our variables in the method, and then the form itself in the admin view.
Here’s the method. Changes for our plugin indicated with highlights.
/**
* Generates the administration form for the widget.
*
* @param array instance The array of keys and values for the widget.
*/
public function form( $instance )
// TODO: Define default values for your variables
$instance = wp_parse_args(
(array) $instance
);
// TODO: Store the values of the widget in their own variable
if ( ! empty( $instance['event'] ) )
$event = $instance['event'];
else
$event = __( 'Event Name', 'wptuts-countdowner-locale' );
if ( ! empty( $instance['event_date'] ) )
$event_date = $instance['event_date'];
else
$event_date = date( 'Y-m-d' );
// Display the admin form
include( plugin_dir_path(__FILE__) . '/views/admin.php' );
} // end form
You’ll note at the end of the method, there’s an include for the view. So open up /wp-content/plugins/wptuts-countdowner/views/admin.php. Add the following code into that file:
Now you can refresh the WordPress Dashboard and add the widget to your sidebar, which will look like this:
/>
Sadly, whatever you put in those fields won’t save yet, so we need to modify the update method as follows:
/**
* Processes the widget's options to be saved.
*
* @param array new_instance The previous instance of values before the update.
* @param array old_instance The new instance of values to be generated via the update.
*/
public function update( $new_instance, $old_instance )
$instance = $old_instance;
// TODO: Here is where you update your widget's old values with the new, incoming values
$instance['event'] = strip_tags( $new_instance['event'] );
$instance['event_date'] = strip_tags( $new_instance['event_date'] );
return $instance;
// end widget
Now we have a working widget admin! You can drag the widget into your sidebar, and save the details for an event, like Christmas:
/>
/>
4. Showing on the Front End
Now we have event details for the countdown time, let’s show it on the front end of the site in the sidebar.
/**
* Outputs the content of the widget.
*
* @param array args The array of form elements
* @param array instance The current instance of the widget
*/
public function widget( $args, $instance )
extract( $args, EXTR_SKIP );
echo $before_widget;
// TODO: Here is where you manipulate your widget's values based on their input fields
$event = apply_filters( 'wptuts_countdowner_event', $instance['event'] );
$event_date = apply_filters( 'wptuts_countdowner_event_date', $instance['event_date'] );
include( plugin_dir_path( __FILE__ ) . '/views/widget.php' );
echo $after_widget;
// end widget
As with the admin form, we’re using a view for the front end too, to keep the HTML separate. Open up your /wp-content/plugins/wptuts-countdowner/views/widget.php file, and add the following:
/>
5. Counting Days
So we have an event and a date / time displaying now, but that doesn’t give us a countdown. We need to add a little bit of code in to determine how many days between our event’s date, and today’s date. Because our date could be in the past or the future, we’ll also need to add a suffix word to indicate which.
Here’s the code we add to the front end part of the widget:
/**
* Outputs the content of the widget.
*
* @param array args The array of form elements
* @param array instance The current instance of the widget
*/
public function widget( $args, $instance )
extract( $args, EXTR_SKIP );
echo $before_widget;
// TODO: Here is where you manipulate your widget's values based on their input fields
$event = apply_filters( 'wptuts_countdowner_event', $instance['event'] );
$event_date = apply_filters( 'wptuts_countdowner_event_date', $instance['event_date'] );
$event_date_seconds = date( 'U', strtotime( $event_date ) );
$today_date_seconds = date( 'U' );
$event_date = human_time_diff( $event_date_seconds );
$suffix = ( $event_date_seconds > $today_date_seconds ? 'away' : 'ago' );
include( plugin_dir_path( __FILE__ ) . '/views/widget.php' );
echo $after_widget;
// end widget
What we’re doing there is getting the current timestamp in seconds for the event, and for today. We then get the human-readable version (i.e. 267 days). We also work out, based on whether the event date is in the past or the future, which suffix word to use.
Now we have a suffix word, we’d better add it to the view:
Now we have something that looks a bit more respectable and makes a bit more sense.
/>
/>
6. Pick a Date
It’s a little ugly to have to manually type in a date, so let’s add in the jQuery UI Datepicker, seeing as it’s included in WordPress.
One thing that isn’t included though, is the CSS for the date picker. So grab the CSS file and images directory from Helen Hou-Sandi’s WP Admin jQuery UI repository on GitHub, and put them into your /wp-content/plugins/wptuts-countdowner/css/ directory.
Then we need to get WordPress to load them by modifying the boilerplate’s register_admin_scripts and register_admin_styles methods, like so:
register_admin_scripts
/**
* Registers and enqueues admin-specific JavaScript.
*/
public function register_admin_scripts()
wp_enqueue_script( 'jquery-ui-datepicker' );
// TODO: Change 'wptuts-countdowner' to the name of your plugin
wp_enqueue_script( 'wptuts-countdowner-admin-script', plugins_url( 'wptuts-countdowner/js/admin.js' ) );
// end register_admin_scripts
register_admin_styles
/**
* Registers and enqueues admin-specific styles.
*/
public function register_admin_styles()
// TODO: Change 'wptuts-countdowner' to the name of your plugin
wp_enqueue_style( 'wp-admin-jquery-ui', plugins_url( 'wptuts-countdowner/css/jquery-ui-fresh.css' ) );
wp_enqueue_style( 'wptuts-countdowner-admin-styles', plugins_url( 'wptuts-countdowner/css/admin.css' ) );
// end register_admin_styles
Finally, add your jQuery code into the boilerplate’s admin.js file to hook the datepicker up to the field.
(function ($)
"use strict";
$(function ()
// Place your administration-specific JavaScript here
jQuery('.wptuts-event-date').datepicker(
dateFormat : 'yy-mm-dd'
);
});
}(jQuery));
/>
7. Cleaning Up
The boilerplate contains a few things we haven’t used in this plugin, so it’d be a good idea to lighten the load and remove them. The extras are these files:
/css/admin.css
/css/widget.css
/js/widget.js
And these methods in the wptuts-countdowner.php file:
activate
deactivate
register_widget_scripts
register_widget_styles
Also line wp_enqueue_style( 'wptuts-countdowner-admin-styles', plugins_url( 'wptuts-countdowner/css/admin.css' ) ); from the register_admin_styles method
/>
Conclusion
There you have it! A WordPress plugin based on the Widget Boilerplate that lets you show how many days until (or since) an event.
I hope you found it useful, please share your thoughts in the comments below.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/6rbsa4FpcJ8/
The WordPress Dashboard is a great place to see updates, or any kind of information related to your activity. In this tutorial, we’ll see how to dispose of default widgets and how to create your own custom widgets.
We are going to create a simple plugin to handle this so it can apply to any theme.
/>
1. Create the Plugin
Create a new folder in the plugins directory (wp-content/plugins) and put a file named dashboard_widgets.php there.
Save it and it will already be available for activation in the plugins page.
We are now going to create the class that will hold our functions.
class Wptuts_Dashboard_Widgets
function __construct()
add_action( 'wp_dashboard_setup', array( $this, 'remove_dashboard_widgets' ) );
add_action( 'wp_dashboard_setup', array( $this, 'add_dashboard_widgets' ) );
function remove_dashboard_widgets()
function add_dashboard_widgets()
}
$wdw = new Wptuts_Dashboard_Widgets();
We will use the wp_dashboard_setup hook to bind two functions:
remove_dashboard_widgets will be used to remove the default widgets
add_dashboard_widgets will be used to add some of our own
Notice the way we bind the functions array( $this, 'remove_dashboard_widgets' ). Because it is a class, you have to tell WordPress the function belongs this class.
/>
2. Define Our Widgets
Let’s create another file named custom_widgets.php. It will contain our widgets definitions (both to remove default and add new ones).
First, let’s add some widgets to be removed. It is basically an array which contains IDs of widgets to remove and information on where to delete them (page and context).
For this purpose, we will use the function remove_meta_box() as dashboard’s widgets are built as metaboxes. The function has three arguments:
ID
Page – Where can we find this widget ( dashboard / post / attachment / … )
Context – In which area is the widget located ( normal / advanced / side )
Then, we define the custom widgets we want to add. To add WordPress custom widgets, we will use the built-in function wp_add_dashboard_widget(). The function takes several arguments:
ID
Title – Title of our widget
Callback – Function to handle the widget’s content
So let’s define our widget and set those parameters. For this tutorial, we’ll create a very simple dashboard widget that will display the current users’ last published posts.
As the callback option required a valid function to handle the widget’s content, let’s add a function for this.
function dashboardWidgetContent()
$user = wp_get_current_user();
echo "Hello " . $user->user_login . ", this is your custom widget. You can, for instance, list all the posts you've published:";
$r = new WP_Query( apply_filters( 'widget_posts_args', array(
'posts_per_page' => 10,
'post_status' => 'publish',
'author' => $user->ID
) ) );
if ( $r->have_posts() ) :
?>
Now we’ve defined the widgets we want to remove from the dashboard as well as the ones we want to create, we can focus back to our class.
/>
3. Do the Magic!
Now, all that’s left to do is to actually add and remove those widgets.
So get back to our class and let’s fill in the blanks left in Step 1.
First of all, let’s include our widgets definition so they’ll be available in our class. Add this line at the top of dashboard_widgets.php:
function remove_dashboard_widgets()
global $remove_defaults_widgets;
foreach ( $remove_defaults_widgets as $wigdet_id => $options )
remove_meta_box( $wigdet_id, $options['page'], $options['context'] );
}
To remove our widgets, we just loop through our $remove_defaults_widgets array and apply the remove_meta_box function with the parameters we set for each widget.
Be sure to “globalize” the $remove_defaults_widgets variable, otherwise you won’t be able to use it.
Add Custom Widgets
function add_dashboard_widgets()
global $custom_dashboard_widgets;
foreach ( $custom_dashboard_widgets as $widget_id => $options )
wp_add_dashboard_widget(
$widget_id,
$options['title'],
$options['callback']
);
}
Exact same process here, except we apply the wp_add_dashboard_widget function.
Now save and go to your dashboard, you should come to something like below:
/>
Conclusion
Now, you can add whatever widget you want to your WordPress’ dashboard, simply by adding options and callbacks to the custom_widgets.php file.
It’s always a good idea to customize the dashboard, especially when it is for a client. You can list their last articles, comments, reminders, etc. So it becomes a convenient place to start from.
Let us know what you think in the comments below, especially if you have more suggestions on customising the WordPress Dashboard for clients.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/u9URryXnAKY/
In this series, we are working on a plugin for the simple purpose of introducing a jQuery date picker into the post editor using a post meta box and then displaying it on the site front end.
Rather than do an extensive, detailed series on a deep topic in WordPress – the purpose of this series is to focus on a very niche topic.
In the first article in the series, we accomplished the following:
Stubbed out the plugin
Created and styled the meta box
Saved the date
In this article, we’ll resume work by implementing the jQuery Date Picker, storing the date in the post, and then preparing the plugin for release.
/>
Completing the Plugin
We’ve already completed three of the six steps needed to implement our plugin. Now it’s a matter of incorporating all of the necessary JavaScript to display the color picker and retrieve the data.
But thanks to WordPress, this really isn’t all that difficult as much of what we need is already bundled with the core application.
4. Implement the Date Picker
To implement the jQuery date picker, we need several dependencies:
The jQuery Date Picker plugin JavaScript
The jQuery Date Picker styles
Some custom JavaScript to display the color picker when the user clicks on the meta box
First, add the following line to your constructor:
Next, we need to actually define the function that will enqueue the jQuery date picker library as well as our own custom JavaScript file.
So go ahead and define register_admin_scripts and the line for including the jQuery date picker:
/**
* Registers and enqueues admin-specific JavaScript.
*
* @version 1.0
* @since 1.0
*/
public function register_admin_scripts()
wp_enqueue_script( 'jquery-ui-datepicker' );
// end register_admin_scripts
Next, introduce a js directory into your plugin and then add an admin.js file to that directory.
The file should contain the following JavaScript:
(function($)
$(function()
// Check to make sure the input box exists
if( 0 < $('#datepicker').length )
$('#datepicker').datepicker();
// end if
});
}(jQuery));
Simply put, this file will execute the JavaScript for each page the dashboard is loaded. There is an alternative way to handle this, but it’s beyond the scope of this article.
Instead, we have our JavaScript check for the existence of the element. If it does exist, then it applies the datepicker plugin to the element.
Finally, we need to register the jQuery Date Picker stylesheet with our plugin. To do this, add the following line to your register_admin_styles function:
At this point, refresh the plugin and you should be able to click on the input element and see something like this:
Pretty cool, isn’t it? Notice that when you select a date it will automatically apply the date to the input element. If you’re interested in customizing the date format (or other aspects of the date picker) even more, be sure to check out its API docs.
5. Display the Date on the Post
At this point, we’re ready to display the date on the actual post. For the purpose of our plugin, we’re going to be prepending this to the content.
To do this, define the following hook in the constructor of your plugin:
Next, we need to actually define the function. It’s really simple, though. Check it out, then I’ll explain it after the code snippet:
/**
* Saves the project completion data for the incoming post ID.
*
* @param int The current Post ID.
* @version 1.0
* @since 1.0
*/
public function prepend_the_date( $content )
// If the post meta isn't empty for `the_date`, then render it in the content
if( 0 != ( $the_date = get_post_meta( get_the_ID(), 'the_date', true ) ) )
$content = '
' . $the_date . '
' . $content;
// end if
return $content;
} // end prepend_the_date
In this function, we’re checking the post meta data for the current post. Since this function fires within the context of The Loop, we’re able to use get_the_ID().
If the date string – that is, the post meta keyed by the_date – isn’t empty, then we’ll wrap it in a paragraph tag and prepend it to the $content; otherwise, we just return the $content as it is.
6. Prepare the Plugin for Release
At this point, there’s only two things left to do:
Provide the localization file for translation
Create the README.
Creating the localization file is simple. Since we defined the plugin.po file in the first article, all that we need to do is open the file with Poedit, click ‘Update’, then save the file. This will generate a plugin.mo file in the lang directory.
Next, we need to create a README file that follows the WordPress Readme conventions. Though you can be as creative as you like, I’ve shared mine below.
=== WordPress jQuery Date Picker ===
Contributors: tommcfarlin
Tags: date, post
Requires at least: 3.5
Tested up to: 3.5.1
Stable tag: 1.0
A sample plugin used to demonstrate how to include the jQuery Date Picker into the post editor.
== Description ==
WordPress jQuery Date Picker is a simple plugin used to demonstrate how to take advantage of custom post meta boxes, meta data, and jQuery plugins to allow users to select dates to be displayed within their posts.
== Installation ==
= Using The WordPress Dashboard =
1. Navigate to the 'Add New' Plugin Dashboard
2. Select `wordpress-jquery-date-picker.zip` from your computer
3. Upload
4. Activate the plugin on the WordPress Plugin Dashboard
= Using FTP =
1. Extract `wordpress-jquery-date-picker.zip` to your computer
2. Upload the `wordpress-jquery-date-picker` directory to your `wp-content/plugins` directory
3. Activate the plugin on the WordPress Plugins dashboard
== Frequently Asked Questions ==
= Right now, the date only appears at the top of the post. Can I change it's position? =
No.
== Changelog ==
= 1.0 =
* Initial release
Nothing groundbreaking – just says exactly what it does.
/>
Conclusion
If you haven’t already, be sure to grab the latest version of the plugin from GitHub, read the comments, and follow along to make sure you understand everything that’s happening in the plugin.
And that’s all – easy enough, right?
As usual, please leave comments and questions in the comment form below.
Original from: http://wp.tutsplus.com/tutorials/plugins/incorporating-the-jquery-date-picker-into-the-post-editor-save-the-date/
Avatar Manager for WordPress is a sweet and simple plugin for storing avatars locally and more. Easily.
Enhance your WordPress website by letting your users choose between using Gravatar or a self-hosted avatar image right from their profile screen. Improved workflow, on-demand image generation and custom user permissions under a native interface. Say hello to the Avatar Manager plugin.
/>
Introduction
A WordPress plugin is a PHP application that adds a specific set of features or services to WordPress, which can be seamlessly integrated with WordPress using access points and methods provided by the WordPress Plugin API.
This article will guide you through the process of creating your own WordPress plugin from scratch.
Note: This article assumes that you are already familiar with the basic functionality of WordPress, and PHP programming.
/>
Step 1. Setting Up the Workspace
To get started navigate to wp-content/plugins/ under your WordPress install. In order to set up the workspace start by creating the following structure of directories and empty files as exemplified in the image below:
/> Workspace structure for the Avatar Manager plugin
Make sure to pick a unique name for the plugin directory and for the main PHP file, such as avatar-manager and avatar-manager.php in this example, and put all the plugin’s files into that directory.
Silence Is Golden
Before starting to write our plugin, open avatar-manager/index.php and add the following code:
You can see this file in many places of WordPress. It’s a simple trick used to prevent directory browsing.
/>
Step 2. Writing a Basic WordPress Plugin
Now, it’s time to put some information into our main plugin PHP file.
Standard Plugin Information
The top of the plugin’s main PHP file must contain a standard plugin information header. This header lets WordPress recognize that the plugin exists, add it to the plugin management screen so it can be activated, load it, and run its functions; without the header, the plugin will never be activated and will never run.
Open avatar-manager/avatar-manager.php and add the following lines:
The minimum information WordPress needs to recognize our plugin is the Plugin Name line. The rest of the information (if present) will be used to create the table of plugins on the plugin management screen. The order of the lines is not important.
So that the upgrade mechanism can correctly read the version of our plugin it is recommended to pick a format for the version number and stick to it between the different releases.
The License slug should be a short common identifier for the license the plugin is under and is meant to be a simple way of being explicit about the license of the code.
Versioning
For transparency and insight into our release cycle, and for striving to maintain backward compatibility, Avatar Manager will be maintained under the Semantic Versioning guidelines as much as possible.
Releases will be numbered with the following format:
..
And constructed with the following guidelines:
Breaking backward compatibility bumps the major (and resets the minor and patch).
New additions without breaking backward compatibility bumps the minor (and resets the patch).
Bug fixes and misc changes bumps the patch.
For more information on SemVer, please visit semver.org.
License
It is customary to follow the standard header with information about licensing for the plugin. Most plugins use the same license used by WordPress, which is the GPLv2 license or a license compatible with the GPLv2. To indicate a GPLv2 license, include the following lines in our plugin:
The define() function defines a named constant at runtime. The plugin_dir_url() function gets the URL (with trailing slash) for the plugin __FILE__ passed in. The value of __FILE__ is the full path and filename of the current file and it’s one of the eight magical constants that PHP provides.
Let’s go further and initialize our plugin:
/**
* Sets up plugin defaults and makes Avatar Manager available for translation.
*
* @uses load_theme_textdomain() For translation/localization support.
* @uses plugin_basename() For retrieving the basename of the plugin.
*
* @since Avatar Manager 1.0.0
*/
function avatar_manager_init()
// Makes Avatar Manager available for translation.
load_plugin_textdomain( 'avatar-manager', false, dirname( plugin_basename( __FILE__ ) ) . '/languages/' );
add_action( 'init', 'avatar_manager_init' );
The add_action() call hooks a function on to a specific action. The init action runs after WordPress has finished loading but before any headers are sent. Also the load_plugin_textdomain() call should be made during init, otherwise users can’t hook into it. But more about this later, when I’ll cover the internationalization of our plugin. The dirname() function returns the parent directory’s path, while plugin_basename() function gets the basename of the plugin.
Hooks, Actions and Filters
Hooks are provided by WordPress to allow a plugin to hook into the rest of WordPress; that is, to call functions in the plugin at specific times, and thereby set the plugin in motion. There are two types of hooks:
Actions – Actions are the hooks that the WordPress core launches at specific points during execution, or when specific events occur.
Filters – Filters are the hooks that WordPress launches to modify text of various types before adding it to the database or sending it to the browser screen.
/>
Step 4. Adding Plugin Options
Next, we’re going to add the plugin options. Allowing for customization makes a plugin far more flexible for the user.
/**
* Registers sanitization callback and plugin setting fields.
*
* @uses register_setting() For registering a setting and its sanitization
* callback.
* @uses add_settings_field() For registering a settings field to a settings
* page and section.
* @uses __() For retrieving the translated string from the translate().
*
* @since Avatar Manager 1.0.0
*/
function avatar_manager_admin_init()
// Registers plugin setting and its sanitization callback.
register_setting( 'discussion', 'avatar_manager', 'avatar_manager_sanitize_options' );
// Registers Avatar Uploads settings field under the Settings Discussion
// Screen.
add_settings_field( 'avatar-manager-avatar_uploads', __( 'Avatar Uploads', 'avatar-manager' ), 'avatar_manager_avatar_uploads_settings_field', 'discussion', 'avatars' );
// Registers Default Size settings field under the Settings Discussion
// Screen.
add_settings_field( 'avatar-manager-default-size', __( 'Default Size', 'avatar-manager' ), 'avatar_manager_default_size_settings_field', 'discussion', 'avatars' );
add_action( 'admin_init', 'avatar_manager_admin_init' );
The admin_init action is triggered before any other hook when a user accesses the admin area. The
target="_blank">register_setting() function registers a setting and its sanitization callback. The add_settings_field() function registers a settings field to a settings page and section. We used them to add our plugin options under the Settings Discussion Screen. The __() function will be explained later, when I’ll cover the internationalization process.
Step 5. Adding the Sanitization Callback
Before writing the sanitization callback, we need to define two more functions, avatar_manager_get_default_options() and avatar_manager_get_options().
The avatar_manager_get_default_options() function returns plugin default options.
/**
* Returns plugin options.
*
* @uses get_option() For getting values for a named option.
* @uses avatar_manager_get_default_options() For retrieving plugin default
* options.
*
* @since Avatar Manager 1.0.0
*
* @return array Plugin options.
*/
function avatar_manager_get_options()
return get_option( 'avatar_manager', avatar_manager_get_default_options() );
The avatar_manager_get_options() function retrieves current plugin options. The get_otpion() function returns the value of the specified option or the default value if the option isn’t in the database.
/**
* Sanitizes and validates plugin options.
*
* @uses avatar_manager_get_default_options() For retrieving plugin default
* options.
* @uses absint() For converting a value to a non-negative integer.
*
* @since Avatar Manager 1.0.0
*
* @return array Sanitized plugin options.
*/
function avatar_manager_sanitize_options( $input )
$options = avatar_manager_get_default_options();
if ( isset( $input['avatar_uploads'] ) && trim( $input['avatar_uploads'] ) )
$options['avatar_uploads'] = trim( $input['avatar_uploads'] ) ? 1 : 0;
if ( isset( $input['default_size'] ) && is_numeric( trim( $input['default_size'] ) ) )
$options['default_size'] = absint( trim( $input['default_size'] ) );
if ( $options['default_size'] < 1 )
$options['default_size'] = 1;
elseif ( $options['default_size'] > 512 )
$options['default_size'] = 512;
return $options;
}
The avatar_manager_sanitize_options() function sanitizes and validates plugin options. The isset() call determines if a variable is set and not NULL. The trim() function strips whitespaces from the beginning and end of a string. The is_numeric() function finds whether a variable is a number or a numeric string. The absint() function converts a value to a non-negative integer.
/>
Step 6. Adding the Setting Fields
Now, it’s time to add the setting fields.
/**
* Prints Avatar Uploads settings field.
*
* @uses avatar_manager_get_options() For retrieving plugin options.
* @uses _e() For displaying the translated string from the translate().
* @uses checked() For comparing two given values.
*
* @since Avatar Manager 1.0.0
*/
function avatar_manager_avatar_uploads_settings_field()
// Retrieves plugin options.
$options = avatar_manager_get_options();
?>
The avatar_manager_avatar_uploads_settings_field() callback prints Avatar Uploads settings field. The checked() function compares two given values and, if the values are the same, adds the checked attribute to the current checkbox. The _e() function will be described later, when I’ll explain the internationalization process.
/**
* Prints Default Size settings field.
*
* @uses avatar_manager_get_options() For retrieving plugin options.
* @uses _e() For displaying the translated string from the translate().
*
* @since Avatar Manager 1.0.0
*/
function avatar_manager_default_size_settings_field()
// Retrieves plugin options.
$options = avatar_manager_get_options();
?>
The avatar_manager_default_size_settings_field() callback prints Default Size settings field.
After adding the setting fields you should be able to locate the plugin options under the Settings Discussion Screen.
The first option controls whether low privileged users can upload an avatar image or not, while the second option represents the default size for an avatar image.
/>
Step 7. Adding the Avatar Section
To allow users manage their avatar, we need to add a new section to their profile page. Let’s go furher and add the Avatar section under the User Your Profile Screen:
/**
* Prints Avatar section.
*
* @uses avatar_manager_get_options() For retrieving plugin options.
* @uses get_post_meta() For retrieving attachment meta fields.
* @uses remove_filter() For removing a function attached to a specified action
* hook.
* @uses _e() For displaying the translated string from the translate().
* @uses checked() For comparing two given values.
* @uses get_avatar() For retrieving the avatar for a user.
* @uses esc_attr() For escaping HTML attributes.
* @uses add_query_arg() For retrieving a modified URL (with) query string.
* @uses self_admin_url() For retrieving an admin url link with optional path
* appended.
* @uses current_user_can() For checking whether the current user has a certain
* capability.
* @uses submit_button() For echoing a submit button, with provided text and
* appropriate class.
* @uses __() For retrieving the translated string from the translate().
*
* @since Avatar Manager 1.0.0
*
* @param array $profileuser User to edit.
*/
function avatar_manager_edit_user_profile( $profileuser )
// Retrieves plugin options.
$options = avatar_manager_get_options();
$avatar_type = isset( $profileuser->avatar_manager_avatar_type ) ? $profileuser->avatar_manager_avatar_type : 'gravatar';
if ( isset( $profileuser->avatar_manager_custom_avatar ) )
// Retrieves attachment meta fields based on attachment ID.
$custom_avatar_rating = get_post_meta( $profileuser->avatar_manager_custom_avatar, '_avatar_manager_custom_avatar_rating', true );
$user_has_custom_avatar = get_post_meta( $profileuser->avatar_manager_custom_avatar, '_avatar_manager_is_custom_avatar', true );
if ( ! isset( $custom_avatar_rating ) || empty( $custom_avatar_rating ) )
$custom_avatar_rating = 'G';
if ( ! isset( $user_has_custom_avatar ) || empty( $user_has_custom_avatar ) )
$user_has_custom_avatar = false;
if ( $user_has_custom_avatar )
// Removes the function attached to the specified action hook.
remove_filter( 'get_avatar', 'avatar_manager_get_avatar' );
?>
...
The show_user_profile and edit_user_profile actions help customization of the user profile page. The $profileuser parameter is a WP_User object of the user being edited. The get_post_meta() function returns the values of the custom fields with the specified key from the specified post. The empty() function determines whether a variable is empty. The remove_filter() function removes a function attached to a specified filter hook; it’s required to remove our custom function for retrieving an avatar image.
Next, we’re going to add an avatar picker, an upload form and a rating chooser for the custom avatar image of each user.
The Avatar Picker
The avatar picker lets a user choose between using Gravatar or a custom avatar image. To add it, write the following code:
The get_avatar() function retrieves the avatar for a user who provided a user ID or email address. To retrievie a custom avatar image by a user ID, we used the avatar_manager_get_custom_avatar() function, which we’ll write later. The current_user_can() function checks whether the current user has a certain capability. Normally, low priviledged users like Subscribers aren’t allowed to upload files; this is why we use the $options['avatar_uploads'] variable. The esc_attr() function escapes HTML attributes. The self_admin_url() function retrieves an admin URL link with optional path appended. The IS_PROFILE_PAGE constant tells us if we’re editing our profile or another user’s profile. The wp_nonce_url() function retrieves URL with nonce added to URL query. Before deleting an avatar, we ask the user to confirm by calling the showNotice.warn() method at the onclick event of the Delete link which displays a warning notice.
The Upload Form
The upload form allows a user to browse and upload a custom avatar image:
The submit_button() function echoes a submit button, with provided text and appropriate class.
The Rating Chooser
The rating chooser shows up only when a custom avatar is available. To add it, write the following lines:
It lets the user choose an appropriate rating for the custom avatar image being used.
/>
Step 8. Adding Scripts and Styles
Now that we’ve added the Avatar section, it’s time to style it. Also, we’ll write some JS to change the form encoding; this step is required because we’ve added a file upload control to it.
The CSS Style
To style our plugin, open avatar-manager/avatar-manager.css and write the following lines:
This aligns an avatar image vertically with a radiobox and styles the Delete link accordingly for a seamless integration with WordPress’ native interface.
The JS Script
Next, open avatar-manager/avatar-manager.js and add the following code:
The .attr() function sets the value of one or more attributes for every matched element. The enctype attribute specifies how the form-data should be encoded when submitting it to the server. We need to change its value to multipart/form-data to allow file uploads.
/>
Step 9. Enqueuing the Scripts and Styles
The safe and recommended method of adding scripts and styles to a WordPress generated page is by using wp_enqueue_script() and wp_enqueue_style(). These functions include the scripts and styles if they haven’t already been included, and safely handle dependencies.
/**
* Enqueues plugin scripts and styles for Users Your Profile Screen.
*
* @uses wp_register_style() For registering a CSS style file.
* @uses wp_enqueue_style() For enqueuing a CSS style file.
* @uses wp_register_script() For registering a JS script file.
* @uses wp_enqueue_script() For enqueuing a JS script file.
*
* @since Avatar Manager 1.0.0
*/
function avatar_manager_admin_enqueue_scripts()
global $hook_suffix;
if ( $hook_suffix == 'profile.php'
}
add_action( 'admin_enqueue_scripts', 'avatar_manager_admin_enqueue_scripts' );
The admin_enqueue_scripts action is the first action hooked into the admin scripts actions. Then, the global variable $hook_suffix is used to add our scripts and styles only on the needed pages. Before enqueuing a script or style, we need to register it first. The wp_register_style() function is a safe way to register a CSS style file for later use; the wp_enqueue_style() function is used to enqueue it. Similarly, the wp_register_script() and wp_enqueue_script() functions are used to register and enqueue our plugin JS script file.
After this step you should be able to locate the plugin options under the User Your Profile Screen.
The first option lets you choose between using Gravatar or a self-hosted avatar image. The second field lets you browse and upload a custom avatar image. The Avatar Rating option shows up only when a custom avatar is available. But more about this later, when we’ll handle avatar uploads.
/>
What’s Next
This completes the first part of our tutorial. I hope you’ve enjoyed the time we’ve spent together and found it to be useful. In the next part we’re going to finish the Avatar Manager plugin; we’ll handle avatar uploads and on-demand image generation, internationalize our plugin and much more. Thanks for reading!
Writing a Plugin – Best starting place for learning about how to develop WordPress plugins.
Plugin API – Description of how to use action and filter hooks in your WordPress plugin, and core functions that plugins can override.
Settings API – A reference with examples for adding new settings to existing settings screens.
Function Reference – An article with many of the core WordPress functions useful to plugin and theme developers; lists most of the core functions, excluding Template Tags.
Recent Comments