Wordpress Leaks

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.

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.

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

role = "Administrator";
	

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

}

?>

The Reader

role = "Reader";
	

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

}

?>

The Volunteer

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.

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.

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!

Original from: http://feedproxy.google.com/~r/Wptuts/~3/ARIEWv5glFM/

Delivery Date Matters

And this brings us to the second point: Despite the fact that you have no one “above you” holding you accountable to your delivery date, you still have an obligation to yourselves, your scope, and those who may be waiting for the product to complete development.

Granted, there’s always the argument that can be made that since people aren’t paying, then they have no real demand on when something should be finished; however, if you’ve set a date, there’s a level of integrity that should be matched when aiming to deliver your work.

What’s a plugin that @nocross and I could build during #wcmia and release for free? #WordPress

— Pippinsplugins (@pippinsplugins) February 13, 2013

To that end, it’s important that you set a delivery date – however arbitrary it may be – and then set milestones to make sure the pace of development matches that date.

For example, Pippin, Andrew, and I scoped the plugin in February and aimed to have the plugin completed in April by the end of one of the WordCamp events. Sure, the deadline was somewhat arbitrary, but it kept us honest not only in our own development efforts, but it allowed us to hold one another accountable for our own specific tasks.

This means that if I was dragging my feet, Pippin or Andrew could call me on it (of course, it works all around).

/>

Keep It Open

Finally, working with friends is great especially when you’re unified around the same vision. It allows you to get more done faster since the work can be spread across more than a single person.

But the nice thing about software is that it can be open sourced. This means that if others are not only interested in the project, or are bought into the vision, they can even contribute to it.

But here’s the thing, software is inevitably going to breed two things:

1. Bugs
2. Feature Requests

Using tools such as GitHub allows the plugin’s user base – be it users, developers, or designers – to voice their issues and/or feature requests in a centralized way.

Furthermore, it allows the core team to not only assign each set of issues to their own milestones, but it allows for other contributors who are also brought into the vision know exactly how they can contribute. There’s no guesswork. There’s no “hey, maybe we could do this!”

Instead, there’s a list of issues and requests that are needed (permitting the list is kept up to date) so that contributors know they are ultimately improving the product – not just blindly adding something because they think it would look good.

Of course, this isn’t limited to GitHub: Whatever source control system and ticket system you opt to use, make sure it’s something that makes it easy for others to interact and others to view outstanding issues. The last thing contributors need is yet-another-hurdle for contributing to your project.

/>

Conclusion

So there you have it: Three points to working on products with a distributed team outside of the typical organized environment.

Simply put, make sure that you scope your project, stick to your delivery date, and allow others to contribute who are interested. By doing this, you’re making it easy not only for your current team, but your future contributors to improve the product.

Finally, I’ve avoided discussing the plugin that Pippin, Andrew, and I built specifically because I wanted this post to be about the process, not the product; however, now that we’ve covered the former, you can find the latter here on GitHub. If you’re interested, feel free to leave us issues, notes, or even pull requests!

Original from: http://feedproxy.google.com/~r/Wptuts/~3/L-j-NNeAuik/

Nettuts+ — Web Development

• 

  Round Table #1: Should Exceptions Ever be Used for Flow Control?

  I’m pleased to release our first ever round table, where we place a group of developers in a locked room (not really), and ask them to debate one another on a single topic. In this first entry, we discuss exceptions and flow control.

  Visit Article

• 

  Pro Workflow in Laravel and Sublime Text

  Not too long ago, I built a handful of generators for Laravel, which ease the process of various tasks. Today, thanks to help from Gaurav Narula, we’re turning things up a notch with the release of a new Sublime Text plugin that leverages the power of Artisan and the generators from directly within your editor.

  Visit Article

• 

  The Command Line is Your Best Friend

  The command line can either be your best friend, or your worst enemy. It simply depends on how you use it, and what you use it for. If you’re one of the many people who cringe at the mere thought of using the command line, then you’ve come to the right place!

  Visit Article

WordPress as a Foundation

When it comes to building products in WordPress, one of the things that we, as developers, need to try to do is to treat the WordPress application as a foundation.

Right now, the API allows us a massive amount of flexibility when it comes to building themes, plugins, and applications, and this is a good thing.

But when we begin to remove libraries that ship with WordPress in favor of our own, it’s almost as if we’re creating a “mini-fork” of the project.

This isn’t a good practice to adopt.

As far as I’m concerned, WordPress ships with its core set of functions and libraries that allow it work the way that it does. Changing out crucial parts of the application – such as jQuery – doesn’t only affect WordPress itself, but the entire ecosystem of products that are built on top of it.

Good themes and plugins depend on the presence of those libraries. When we change that functionality, we potentially break every piece of work that’s depending on them.

We need to stop viewing WordPress as something that we can take apart and reassemble as we need it, and view it as a foundation off of which to build our own unique work.

(function( $ ) 
	"use strict";

	$(function() 

		// Your code here

	);

}(jQuery));

2. Getting Client ID and Secret

This step is needed for every new plugin. Register it at Instagram to get a client_id and client_secret. The plugin name should be simple alphabetical characters in my experience (eg. johnsplugin).

/>

3. Plugin Information

This is the place to describe your plugin’s base data like plugin name, url, version number, and author.

/*
Plugin Name: Instagradam
Plugin URI: http://wp.tutsplus.com/
Description: A simple and fast Instagram shortcode plugin. Please use [instagradam] to pull main feed!
Version: 1.0
Author: Adam Burucs
Author URI: http://burucs.com/
*/

/>

4. Registering the Shortcode

This will define the [instagradam] shortcode, which will work based on the instagradam_embed_shortcode function.

	// register shortcode
	add_shortcode( 'instagradam', 'instagradam_embed_shortcode' );

/>

5. Defining Main Function for the Shortcode

This will describe our plugin’s core operation. The $atts and $content should be defined as we see here, but we won’t use them in this lesson.

	// define shortcode
	function instagradam_embed_shortcode( $atts, $content = null ) 

		// ...

	

/>

6. Making Variables

We need a helper variable for making an output for our function and a data retrieval which uses the WordPress Function API. That is $str and $result, respectively.

		// define main output
		$str    = "";
		// get remote data
		$result = wp_remote_get( "https://api.instagram.com/v1/media/popular?client_id=3f72f6859f3240c68b362b80c70e3121" );

/>

7. Handling Feed Errors

The main selection handles the feed error (in some cases we can get SSL errors, but there is a fix for that described later in this article).

If there is any error we echo it to the page: Something went wrong: ... .

	if ( is_wp_error( $result ) ) 
		// error handling
		$error_message = $result->get_error_message();
		$str           = "Something went wrong: $error_message";
	 else 
		// processing further
		// ...
	

/>

8. More Variables

Variable $result will contain the main data, for processing we make another helper called $main_data. We also need a counter for the iteration.

// processing further
$result    = json_decode( $result['body'] );
$main_data = array();
$n         = 0;

/>

9. Looping, Part One

This loop will collect all usernames and thumbnails we need. Previously I analyzed the main feed (the structure of the feed), to discover how to get the data I want. So this is an important step and also let’s not forget that Instagram can change this later /> and we might need to modify $d->user->username and $d->images->thumbnail->url.

	// get username and actual thumbnail
	foreach ( $result->data as $d ) 
		$main_data[ $n ]['user']      = $d->user->username;
		$main_data[ $n ]['thumbnail'] = $d->images->thumbnail->url;
		$n++;
	

/>

10. Looping, Part Two

In the following lines, we create the HTML code which will contain the pictures and links from the Instagram main feed. The links will open in a new window, made with target="_blank". Note the space at the end of the main string, this is for basic separation.

	// create main string, pictures embedded in links
	foreach ( $main_data as $data ) 
		$str .= ' ';
	

/>

11. The Easy Part

This (shortcode) standard code will return our main content.

	return $str;

/>

12. SSL Problems

In some cases the wp_remote_get function can work badly, to solve this we need to use this code before the main code sections.

	// fix SSL request error
	add_action( 'http_request_args', 'no_ssl_http_request_args', 10, 2 );
	function no_ssl_http_request_args( $args, $url ) 
		$args['sslverify'] = false;
		return $args;
	

/>

13. Complete Code

The finished code looks like this.

/*
Plugin Name: Instagradam
Plugin URI: http://wp.tutsplus.com/
Description: A simple and fast Instagram shortcode plugin. Please use [instagradam] to pull main feed!
Version: 1.0
Author: Adam Burucs
Author URI: http://burucs.com/
*/

	// fix SSL request error
	add_action( 'http_request_args', 'no_ssl_http_request_args', 10, 2 );
	function no_ssl_http_request_args( $args, $url ) 
		$args['sslverify'] = false;
		return $args;
	

	// register shortcode
	add_shortcode( 'instagradam', 'instagradam_embed_shortcode' );
	
	// define shortcode
	function instagradam_embed_shortcode( $atts, $content = null ) 
		// define main output
		$str    = "";
		// get remote data
		$result = wp_remote_get( "https://api.instagram.com/v1/media/popular?client_id=3f72f6859f3240c68b362b80c70e3121" );

		if ( is_wp_error( $result ) ) 
			// error handling
			$error_message = $result->get_error_message();
			$str           = "Something went wrong: $error_message";
		 else 
			// processing further
			$result    = json_decode( $result['body'] );
			$main_data = array();
			$n         = 0;

			// get username and actual thumbnail
			foreach ( $result->data as $d ) 
				$main_data[ $n ]['user']      = $d->user->username;
				$main_data[ $n ]['thumbnail'] = $d->images->thumbnail->url;
				$n++;
			

			// create main string, pictures embedded in links
			foreach ( $main_data as $data ) 
				$str .= ' ';
			
		}

		return $str;
	}

/>

Finished Look

This is a picture showing the plugin in action. For this, the shortcode was inserted in an article.

/>How it looks in a browser

Original from: http://wp.tutsplus.com/tutorials/plugins/creating-instagram-plugin/

Planning the Plugin

For anyone that’s read any of my previous posts, you know that I’m a fan of planning the project from the outset, then implementing each step at a time to make sure we’re clear on everything that’s happening.

So let’s do that now:

• We’ll provide the skeleton class for the plugin
• We’ll write the code responsible for generating the post meta box that allows the user to select the date
• We’ll implement the jQuery date picker so users can actually select a date
• We’ll save the data when the post is published and/or updated
• We’ll display the date on the front end of the post

Straightforward, right? With that said, let’s get started.

Obviously, there’s not much to it, yet. We’ve simply defined the class, set an empty constructor, and instantiated the plugin outside the class.
Before we move any further, let’s go ahead and prepare the plugin for localization. To do this, we need to do several things:

Introduce a lang directory
Add lang/plugin.po
Set the text domain for the plugin within the constructor

Remember that localization is used to be sure that translators can make our plugin compatible with other languages, and that Poedit is the tool of choice.
The plugin.po file should contain something like the following (yours will obviously be different based on the date, the time, and the configuration of Poedit):
msgid ""
msgstr ""
"Project-Id-Version: WordPress jQuery Date Picker 1.0n"
"Report-Msgid-Bugs-To: n"
"POT-Creation-Date: 2013-02-07 13:36-0500n"
"PO-Revision-Date: 2013-02-07 13:36-0500n"
"Last-Translator: Tom McFarlin n"
"Language-Team: Tom McFarlin n"
"Language: en_USn"
"MIME-Version: 1.0n"
"Content-Type: text/plain; charset=UTF-8n"
"Content-Transfer-Encoding: 8bitn"
"X-Poedit-KeywordsList: __;_en"
"X-Poedit-Basepath: .n"
"X-Generator: Poedit 1.5.5n"
"X-Poedit-SearchPath-0: ..n"

Next, we need to set the text domain in the constructor. First, include the following line in your constructor:
// Load plugin text domain
add_action( 'init', array( $this, 'plugin_textdomain' ) );

Next, add the following function to your file:
/**
 * Loads the plugin text domain for translation
 *
 * @version		1.0
 * @since 		1.0
 */
public function plugin_textdomain() 
	load_plugin_textdomain( 'wp-jquery-date-picker', false, dirname( plugin_basename( __FILE__ ) ) . '/lang' );
 // end plugin_textdomain

The most significant thing to note here is the use of the wp-jquery-date-picker key as this is what we’ll be using to localize the strings throughout the remainder of the plugin.
Finally, we’ll revisit this along with the README file later in the tutorial.
2. Create the Meta Box
At this point, we’re ready to define the code that will render the meta box. This consists of several steps:

Defining the hook in the constructor
Register the meta box with WordPress
Defining a function used to render the actual meta box

In the constructor, add the following line of code. This is what we’ll be using to register our post meta box:
add_action( 'add_meta_boxes', array( $this, 'add_date_meta_box' ) );

In the function above, we’re telling WordPress to look for our date meta box in a function called add_date_meta_box, so we need to define that now.
Within your class, add the following code:
 /**
  * Registers the meta box for displaying the 'Date' option in the post editor.
  *
  * @version	1.0
  * @since 		1.0
  */
 public function add_date_meta_box() 

	 add_meta_box(
	 	'the_date',
	 	__( 'The Date', 'wp-jquery-date-picker' ),
	 	array( $this, 'the_date_display' ),
	 	'post',
	 	'side',
	 	'low'
	 );

  // end add_date_meta_box

We’ve covered meta boxes in depth in various tutorials and the WordPress Codex has a terrific article explaining what each parameter does, so I don’t want to belabor the point here.
That said, there’s one specific thing that we need to notice in the call above. Note that the meta box is looking to register its display using a function called the_date_display.
As such, we need to define this function. Luckily, the meta box can be very simple: In order to trigger the date picker, we only need a single element. Since we’re going to be rendering the date, let’s opt to use a simple input box.
Next, add the following function to your class:
/**
 * Renders the user interface for completing the project in its associated meta box.
 *
 * @version 1.0
 * @since   1.0
 */
public function the_date_display( $post ) 

	wp_nonce_field( plugin_basename( __FILE__ ), 'wp-jquery-date-picker-nonce' );

	echo '';

 // end the_date_display

Easy to understand, right?
We define a nonce value for security purposes giving us the security features we need to make sure that the user has permissions to save values for this field, and then we render an input element to the screen.
Note that the input element includes an ID of “datepicker” and a name of “the date.” This will be imported later, but for now save your work.
If you activate the plugin right now, you should see something like the following:

Obviously, this needs some light styling to make it look just a little bit better. So, let’s do the following:

Create a css directory
Add a css/admin.css file

In the file, include the following code:
#datepicker 
	width: 100%;


Then, in the constructor, add this line:
add_action( 'admin_print_styles', array( $this, 'register_admin_styles' ) );

After that, add this function to your plugin:
/**
 * Registers and enqueues admin-specific styles.
 *
 * @version		1.0
 * @since 		1.0
 */
public function register_admin_styles() 
	wp_enqueue_style( 'wp-jquery-date-picker', plugins_url( 'WordPress-jQuery-Date-Picker/css/admin.css' ) );
 // end register_admin_styles

At this point, the width of the input box for the date picker should span the width of the meta box’s container. Makes it look just a little bit nicer, in my opinion.
3. Save the Date
Before we actually begin implementing the date picker, let’s go ahead and make sure that our new post meta box can properly save information. Right now, it’s not possible because we haven’t written the code for it.
This particular step will entail the following:

Defining a function for saving the data
Making sure that the user has the ability to save the data
Actually saving the data

First, we need to define the hook for saving the data. To this, add the following line to your constructor directly under the line where we defined the hook for creating the meta box:
add_action( 'save_post', array( $this, 'save_project_date' ) );
1

Next, we need to actually define the save_project_date function. This function is going to be responsible for making sure that the user has permission to save the data and then will actually save the contents of the input field in the post meta for the associated post.

So, add the following function to your plugin:

1
 /**
  * Saves the project completion data for the incoming post ID.
  *
  * @param		int		The current Post ID.
  * @version	1.0
  * @since 		1.0
  */
 public function save_the_date( $post_id ) 

	 // If the user has permission to save the meta data...
	 if( $this->user_can_save( $post_id, 'wp-jquery-date-picker-nonce' ) ) 

	 	// Delete any existing meta data for the owner
		if( get_post_meta( $post_id, 'the_date' ) ) 
			delete_post_meta( $post_id, 'the_date' );
		 // end if
		update_post_meta( $post_id, 'the_date', strip_tags( $_POST[ 'the_date' ] ) );

	 } // end if

 } // end save_the_date
 
This function works by basically checking to see if this user can save. If so, then it will delete any existing post meta so as not to clutter the database, then add the date specified to this post.
But there’s a catch: We’re making a call to a function called user_can_save. This particular function is a helper function that we need to define as it simplifies a lot of the boilerplate code necessary for making sure the user has permission to save the file.
So in the “Helper Functions” area of your class, add the following function:
 /**
  * Determines whether or not the current user has the ability to save meta data associated with this post.
  *
  * @param		int		$post_id	The ID of the post being save
  * @param		bool				Whether or not the user has the ability to save this post.
  * @version	1.0
  * @since		1.0
  */
 private function user_can_save( $post_id, $nonce ) 

    $is_autosave = wp_is_post_autosave( $post_id );
    $is_revision = wp_is_post_revision( $post_id );
    $is_valid_nonce = ( isset( $_POST[ $nonce ] ) && wp_verify_nonce( $_POST[ $nonce ], plugin_basename( __FILE__ ) ) ) ? true : false;

    // Return true if the user is able to save; otherwise, false.
    return ! ( $is_autosave  // end user_can_save

Notice that this function takes in the current Post ID and the nonce value (which we set earlier in this post). Finally, this function returns true if this is not an autosave, a post revision, and that the nonce is valid.
If it’s true, then the user has permission to save.

/>

Conclusion
At this point, let’s try out what we have. Activate the plugin, and you should see the meta box on the Post Editor dashboard. Right now, you should be able to save any value that you’d like in that particular field.
You can grab a copy of the plugin in its current version for this post using this link.
In the next article, we’re going to take a look at actually implementing the date picker. This will include importing the necessary JavaScript dependencies, writing a little bit of our own JavaScript, and then rendering the date on the front end of the post.
Finally, we’ll prepare the plugin for release by generating the localization files and then preparing the README.

Original from: http://wp.tutsplus.com/tutorials/plugins/incorporating-the-jquery-date-picker-into-the-post-editor-preparing-the-plugin/
			

		

Extra Fields

It is very easy for us to remove the contact methods we don’t want to use and replace them with something a little more current. So first things first you need to open up your theme’s functions.php (or stick this in a plugin if your prefer) and let’s get to work.

	function wptuts_contact_methods( $contactmethods ) 

		// Remove we what we don't want
		unset( $contactmethods[ 'aim' ] );
		unset( $contactmethods[ 'yim' ] );
		unset( $contactmethods[ 'jabber' ] );

		// Add some useful ones
		$contactmethods[ 'twitter' ] = 'Twitter Username';
		$contactmethods[ 'facebook' ] = 'Facebook Profile URL';
		$contactmethods[ 'linkedin' ] = 'LinkedIn Public Profile URL';
		$contactmethods[ 'googleplus' ] = 'Google+ Profile URL';

		return $contactmethods;
	

	add_filter( 'user_contactmethods', 'wptuts_contact_methods' );

So first thing we are doing is removing some fairly useless fields, next we simply add the additional fields we want. The first part needs to be unique for the text you can enter whatever you like as this is what will be displayed next to the field on the profile page.

If you revisit your edit profile page you should now see your additional fields have appeared and the useless ones have disappeared.

Now we have somewhere we can store our additional information we can move on to working with the data and how we can show it in the front end of our site.

/>

Show Yourself Off

So we want to show a picture of our author, a little description / bio and some links to social media sites.

WordPress handles user profile pics using Gravatar. We want to use the WordPress Function get_avatar() this retrieves the Gravatar for the specified user ID or email address.

You can specify the size of the image and also what to do if the user doesn’t have a Gravatar. The final parameter allows you to set the Alternate text for the avatar. For now we are going to use the following code:

This pulls in the Gravatar at 70px x 70px and uses the user ID of the author for the current post.

We also want to pull some of the basic user profile information through like the user’s display name and description. Let’s have a look at a basic example.

/>

The Basics

	


		

		


			


			


			


				
					→', 'tuts_plus' ), get_the_author() ); ?>
				

			

		

	

The above code gives a nice starting point. Open up your single.php (I am using Twenty Twelve for the purposes of this article) and paste in the above code inside the loop but above your comments template. (Line 25 if you are using Twenty Twelve as well.) Now let’s go through what we’re doing.

We’ve already talked about the get_avatar() function but further down you will see the get_the_author() function. This simply retrieves the post author. In our example we print the author’s name at the top of our author box. It will display whatever the user has selected as their “Display name publicly as”. You could simply use:

However I prefer to escape all my output and allow the option for translators.

Next we see get_the_author_meta(). We’re going to be using this quite a bit. This function returns the desired meta data for the given user. If we use it within a loop we don’t need to specify the user ID however it can be used outside of the loop by passing the user ID. Using this function you can get a range of information, in the above example we are using it to pull the description which is the biography box you can complete on the user profile page. As with the author name I’m escaping the output to make sure our authors haven’t hidden any nasties!

Finally we have a link at the bottom which links through to our author page. We use the get_author_posts_url() function to simply give us the URL. WordPress automatically creates author pages for all users of the site who have published posts.

Let’s add some CSS and see how it looks:

	.media, .bd  overflow: hidden; _overflow: visible; zoom: 1; 
	.media img, .media .img  float: left; margin-right: 10px; 
	.media img  display: block; 
	.media .imgExt  float: right; margin-left: 10px; 
	.profile  margin-top: 10px; padding: 20px 10px; border: solid thin #c6c6c6; -webkit-box-shadow: 7px 7px 5px rgba(50, 50, 50, 0.75); -moz-box-shadow: 7px 7px 5px rgba(50, 50, 50, 0.75); box-shadow: 7px 7px 5px rgba(50, 50, 50, 0.75); 
	.profile-links  padding: 5px 0; 

/>

Social Shizzle Wizzle

So we’ve got a basic box, but what about all those extra fields we added? We can use the get_the_author_meta() function to retrieve those custom fields just as we did with the description. Let’s go through the following example together, a replacement for our previous “profile-links” div:

	


		

			
				

			

			
				

			

			
				

			

			
				

			
		

		
			→', 'tuts_plus' ), get_the_author() ); ?>
		

	

We’ve created an unordered list and each list item will be our extra fields we added at the start of the article. Firstly we do a crude check to make sure that there is a value entered for each of them as we don’t want links appearing that don’t do anything. Next we create a link based on the information entered in the user profile. As you can see from the example we form the link by using the same get_the_author_meta() function, however depending on what we are outputting we use a different validation function. For the Twitter link as we are only entering a username and appending that to our link we strip any HTML from it using wp_kses() for the others as we are entering full profile URLs into our profile page we are using esc_url() to ensure they are properly formed URLs. I’ve shown you two different ways of doing it so you can see how flexible it can be.

By adding a little more CSS we can style it and we’re almost done!

	.social-links li  padding: 5px; display: inline; list-style: none; text-indent: -9999px; float: left; 
	.social-links li a  background-position: 0 0; background-repeat: no-repeat; width: 16px; height: 16px; display: block; 
	.twitter-link  background: url( images/twitter.png ) no-repeat; 
	.facebook-link  background: url( images/facebook.png ) no-repeat; 
	.linkedin-link  background: url( images/linkedin.png ) no-repeat; 
	.google-link  background: url( images/google-plus.png ) no-repeat; 

The CSS I am using for demonstration purposes only you can of course do what you like with your own styling!

/>

Getting Fancy

Now we have our basic box we can add all kinds of extra features. We’re going to create a dynamic LinkedIn Profile Card when you hover over the LinkedIn icon.

First up we need to create some functions. We need to enqueue the LinkedIn JavaScript library on our blog posts and our author pages (more on this later!).

	function wptuts_linkedin_js() 
		if ( is_single() 

	add_action( 'wp_enqueue_scripts', 'wptuts_linkedin_js' );

Add the above code to your theme functions.php or wherever your added the code to change your contact methods. This will ensure we now have the required JavaScript loaded but only on pages where it is needed.

Next up we are going to create a little function to perform the hover functionality based on the author we are looking at:

	function wptuts_linkedin( $author ) 
		$authorinfo = get_user_meta( $author );
		$linkedin = $authorinfo['linkedin'][0];

		if ( isset( $linkedin ) ) : ?>
			
		
First thing you should notice is that we actually need to pass a parameter to this function when we call it. We want to pass the user ID of the author we want to create the hover card for. Essentially what we are doing is getting the user meta data using get_user_meta() we then pull out our LinkedIn URL that we created in the first half of the article. Then simply add that variable into our LinkedIn JavaScript so that it returns the correct user hover card. Here’s the updated single.php extract:
	


		

			
				

			

			
				

			

			
				

			

			
				

			
		

		


		
			→', 'tuts_plus' ), get_the_author() ); ?>
		

	

As you can see we call our LinkedIn function by using wptuts_linkedin( get_the_author_meta( 'ID' ) ) this passes through the user ID of the correct author to be used in our function. A couple of simple CSS tweaks to make it show properly:
	.linkedin-link  text-indent: 0 !important; 

As you can see now we have our author box with a nice hover card for our LinkedIn profile!


/>

Author Page
It’s often nice to show this author box at the top of an author’s archive page. Twenty Twelve already does some of the work for us in author.php. So we can add what we’ve learnt above to add our extra information.
	

		

			
		

		

			

			


			


				

					
						

					

					
						

					

					
						

					

					
						

					
				

				


			
		

	




/>

Conclusion
So there we have it. You now know how to alter your contact methods, how to pull different information from a user profile and display it on their blog posts. There is so much more you can do depending on what you want to achieve. Try adding a link to the user’s website, display their latest Tweets, pull a commit history from GitHub; the options are endless. All the final code can be found below.
Vector Social Media Icons by IconDock.com & Double-J Design
URL: http://icondock.com/free/vector-social-media-icons

Original from: http://wp.tutsplus.com/tutorials/creative-coding/show-yourself-off-with-a-custom-author-box/
			

		

The Support Models

We’re going to look at four different models for offering support. I want to be clear that this is not the definitive list of support options, but a few of the most common support models that developers use today.

Premium Support

One way that developers offer support is through some type of closed system. This doesn’t necessarily mean that all questions must be answered with payment – only those that are more involved or that require a significant time for troubleshooting.

The advantage to using this model is that there is obviously financial compensation for the time spent in helping the user. Often times, users are happy to pay assuming that the price is reasonable, and that the problem is significant enough; however, this can spur some bit of push back as users who believe that a free plugin should come with free support may also reject this.

It’s a fine line to balance, for sure, and I agree that plugins should all work under a certain set of conditions; however, I don’t believe that every problem that crops up is insignificant enough to warrant free support.

There are so many different permutations of hosting environments, WordPress versions, conflicting plugins, and other factors that isolating the problem can be challenging enough.

WordPress Plugin Repository

The WordPress Plugin Repository is often under-rated, in my opinion. It offers a variety of really nice tools for plugin developers that are simply under utilized either by the developers or by the users.

Aside from offering a consistent experience across the board for all developers and users, it gives us:

• A way to brand our work using the header image
• An easy way to provide a clear description of our work
• Instructions on how to install the plugin
• A section for Frequently Asked Questions
• A Support Forum
• …and much more

The problem is that you often have to consistently check back to the plugin pages to see if any new topics have been opened. On top of that, many of the people who leave topics are used to the plug-and-play model of themes and other plugins which can cause erradict results thanks to poor coding practices, conflicts, or some other anomaly.

Even still, the Support Forum isn’t bad – it’s free, it’s available for each plugin that we release, and it provides a consistent experience for the users. It’s worth considering, but it does require a bit of extra effort on the developer’s behalf.

Email

Email is a slippery slope when it comes to offering support, because it has a slightly more personal feel to it than one of the available forum options. As soon as you begin offering support through email, you’ve essentially given a user permission to contact you regarding a number of other issues either with their plugins or with WordPress problems they may have.

I’m not sharing this out of ignorance, either. This has happened more than a few times with me (and I do take full responsibility for it). Secondly, the problem with using email for support is that it has absolutely no visibility.

It provides no value to anyone except the person(s) in the email thread. This means the potential for duplicate support is really high.

No Support

Finally, one extreme option is simply to offer no support. I’m not particularly advocating this strategy, but I have seen it done, though I can’t speak to its results.

But if you’re offering a free plugin and you’re actively maintaining it, one option is to simply put it out in the wild and let the users fend for themselves.

It’s a dangerous route to go as I think that, as developers, we have some responsibility to our users since we’re attempting to create something to solve a problem for them, but that’s just one subjective stance on the topic. I’d love to hear others’ thoughts on it.

Improving Comments Section With Disqus

Every system has its own pluses and minuses. Nothing is going to be perfect. So let’s discuss the things we need to take into consideration before choosing Disqus as our blog commenting system.

Our discussion from here on will focus on comparing Disqus features against the default WordPress comments based on the sections we created in first part of this series.

Focusing on Simplicity

“Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage to move in the opposite direction.” /> ― E.F. Schumacher

As the above quote suggests, achieving simplicity is the hardest thing in any task. So lets see how Disqus helps us to simplify the comments system.

• User Registration

  If you want to comment on a Disqus enabled blog, you need to register an account first. (At least with default settings). This looks like a certain disadvantage to start our discussion. But don’t rush into making decisions too quickly as Disqus provides the alternative option to comment with your social profiles like Twitter and Facebook.

  

  These days almost all Internet users are on social networking sites like Twitter, Facebook and Google Plus. Hence there is a high percentage of possibility that they will be logged into one of these accounts at any given time.

  So it’s one click away from commenting, which seems fairly easy for a reader.

  Also we get the added advantage as authors or blog owners of social sharing links being provided automatically in line with every comment, increasing the possibility of readers sharing on their social profiles.

• Comment Fields and Captcha

  Disqus doesn’t have a comment form with a lot of fields. A mandatory section is given to enter your comment. Other form fields depend on the chosen login section by the readers.

  If the readers are already logged into Disqus or social accounts, they can choose to enter the comment only. Readers who are not already logged in need to enter their username and password to login.

  In the worst case, readers need to fill only two fields, which is a simple enough task.

  

  No captcha image is used since not many people will waste time on getting authenticated and making spam comments. Disqus admin panel can also be used to filter and remove spam comments if necessary.

  So I would see this as a plus for making it easier for the reader to comment quickly.

• Title of Comments Section

  Disqus default system provides a standard comment area for all users. So we won’t be able to create catchy titles to attract readers to comment, without digging into the Disqus plugin code. So I will consider this as the first minus point on Disqus.

Unique Identity for Readers

Sometimes people use anonymous or false names to comment. As a commenter, you won’t get any benefit by doing that. Also, other readers who read the comments section will feel these are just dummy comments since there is no real person.

We love to hear and learn from real people. For example, I could have written this article without creating my author biography. Since I have it under this article, you know I exist and my qualification to write such articles.

I am sure that you might be much more interested in this article if I had created this as a video explaining these things right in front of you.

Similarly we need to show our unique identity through our comments.

• Commenter Profile Details and Image

  The profile image is one of the major parts in showing a unique identity for users. The default WordPress comments system uses a gravatar image for the given email address. Therefore if the email doesn’t have a gravatar image, a default image for the site will be shown instead.

  With Disqus you should be using either Disqus or Social accounts to comment. Therefore you will get the main profile image of your account in front of your comment which makes it easy to identify you.

  

  Additionally, profile details of your social or Disqus account are displayed when you click on the name of the comment author. This is a really cool way of marketing your social media profiles with your comments.

  

  So this can be considered as a really huge plus compared to the default WordPress comments section.

• Highlight Author Comments

  You can use both a Disqus account and social media profiles to respond to comments, instead of WordPress login. So email cannot be used to identify the author, making it difficult to highlight author comments.

  I see this as a major minus point since it’s difficult to identify the author inside a Disqus comments thread. I hope we can find a method to get it to work with the default system without modifying code.