Wptuts+

Tuts+ Jobs is now free!

Joel Bankhead — Tue, 18 Jun 2013 15:11:18 +0000

Our awesome new job board is now free and full of enticing opportunities!

Tuts+ Jobs is a job board for full time, part time and casual employment opportunities for web and creative professionals. A brand new site to go alongside the Tuts+ Educational Network and the Envato Marketplaces, all run by Envato.

There’s no need to sign up to apply for jobs, and it’s now free to post a job – try it now!

Earn and Learn

Envato is committed to helping people earn and learn online. We provide a wealth of educational material through Tuts+ and Tuts+ Premium, alongside the Envato Marketplaces to help you benefit from the creative skills you learn.

Tuts+ Jobs furthers this vision perfectly. With Tuts+ you can learn the skills you need to become a creative professional, and with Tuts+ Jobs you can find an amazing job that uses those skills. Our goal here is to take the hassle out of finding a job, so we’ve made the process as simple as can be!

Finding a Job

With Tuts+ Jobs we’re committed to making every step of the job-finding process more intuitive, simpler and more efficient. We don’t want to stand between you and a great opportunity.

It’s totally free to sign up and start applying for jobs, and if nothing matches your initial search you can receive notifications when jobs come up that match your criteria. We will have full time, part time and casual listings from all around the world. Check the listing to find out where the job is based, as some jobs may offer remote opportunities.

Posting a Job

Posting a job is now free!

If you have a position that you need to fill, or a great part/full-time opportunity, then Tuts+ Jobs is the best way to find a talented and creative individual to do that job. Each 30-day listing is completely free, regardless of the type of job you’re posting.

Your job listing will be promoted across the entire Tuts+ network. With exposure to our ten million visitors over the course of 30 days, it’s a brilliant way to reach exactly the type of audience you’re looking for.

Sign Up, Explore, and Subscribe

There are lots of great opportunities already on Tuts+ Jobs, and we’ll be posting even more exciting job positions over the next few weeks, so now is the best time to head over to the site and subscribe to a job search that interests you. That way you’ll be the first to know when any new listings show up that match your skill set and requirements.

Check out Tuts+ Jobs

An Introduction to Thesis: Overview

Sarah Frantz — Mon, 17 Jun 2013 13:33:55 +0000

This entry is part 1 of 1 in the series An Introduction to Thesis

If you develop with WordPress you have probably heard the term “framework” before, and chances are you’ve developed with one.

If you haven’t, you’re in luck! This tutorial will walk you through the ins and outs of one of the most popular WordPress frameworks: A framework that over 55,000+ people are using – Thesis.

Thesis was created by Chris Pearson and launched back in March of 2008. The framework at its core was built to be “search engine friendly” and extremely fast loading, however many would argue that Thesis’ best feature is its Visual Design Template Editor.

To fully understand how to develop with Thesis, it’s best to dissect and familiarize yourself with the Thesis settings and the template editor. It’s also important to grasp the concept of boxes, skins and packages – which is what this tutorial series will help you understand by walking you through creating your first, customized Thesis skin.

What We’ll Be Covering

Thesis Building Blocks & User Interface – Introducing you to the Thesis user interface as well as building blocks associated with developing for WordPress on the Thesis Framework.
Setting Up Site Information & Useful Tips – A run-down of available “site” options you can control using the Thesis Framework as well as tips for setting up your Thesis site. We’ll also go through the initial stage of creating your skin for development.
Skins & Layout Structure – A comprehensive walk through focusing on creating and assigning page templates, re-using your templates for further development of other pages, and how to prepare your skin for packages.
CSS & Packages – This section will focus on teaching you how to create and apply a package to your Thesis skin as well as go over how to use the more complicated packages, such as columns.

For the sake of those reading, this tutorial assumes that you’re already familiar with WordPress theme development, HTML and CSS; however, even the most novice user can figure out the basics of creating a skin for their website as Thesis is very “end user oriented.”

In fact, the entire framework utilizes “drag and drop” for just about everything, making adjustments is as easy as holding the shift key and dragging boxes around the template editor.

The Building Blocks of Thesis

To build your WordPress site using Thesis you need to first understand the basic components of the Thesis Framework. Thesis consists of three main elements:

Skins – Skins are essentially the same concept as WordPress themes; however, a Thesis skin utilizes all of the WordPress functionality from the get go – that is to say that skins are rooted into WordPress in such a way that you can do more than just “theme” your site, you can create admin pages, control functionality and much more.
Boxes – Boxes are very similar to “plugins” or “widgets” that can be used in conjunction with your skin. They are bits of code that add dynamic functionality to your site – for example, you could create a box for a content slider, form, author information, HTML structure, etc.
Packages – Packages add style to all aspects of your skin without actually having to dive into CSS code. In fact, Thesis goes so far as to provide users with an easy interface that allows those who aren’t CSS ninjas to input their own margins, borders, widths, heights, etc. making customization easy for beginners.

It’s important to also point out that Thesis comes with a rather robust section dedicated solely to handling your website’s other pertinent information, such as built in support for Google Analytics tracking codes, 404 page handling, and SEO options (i.e. setting your title tag, meta description, keywords and robot options).

Conclusion

Working together, Thesis skins, boxes and packages seamlessly create a WordPress website that utilizes all of the plugin/widget functionality you need – without all the load time and in a very “search engine friendly” way.

Now that you have a basic understanding of Thesis, in our next installment we will dive deeper into setting up our site information using the Thesis settings and start building our first Thesis skin.

The WordPress Coding Standards: Indentation, Space Usage, and Trailing Spaces

Tom McFarlin — Thu, 13 Jun 2013 13:07:52 +0000

This entry is part 4 of 4 in the series The WordPress Coding Standards

The entire purpose of this series to help expose the WordPress Coding Standards, why they matter, and how to write quality WordPress code. In order to do this, we’re taking an in-depth look at each section of the WordPress Coding Standards.

So far, we’ve covered:

Naming Conventions and Function Arguments
Single Quotes and Double Quotes

Today, we’re going to be covering the importance of white space. Specifically, we’re going to cover indentation, space usage, and trailing spaces. As easy as it sounds, these are several of the most ignored or misused aspects of the codings standards.

A Word About Whitespace

Before we look at what’s going on with the various coding standards, it’s important to understand why white space is important not only in WordPress, but in programming languages in general.

Simply put, it’s because it enhances readability.

This is why some programming languages are space or tab delimited, this is why some programming languages ask that you space out certain parts of the code such as function parameters, array indexes, and more.

When it comes to WordPress, the conventions are in place not only for readability, but also to provide a consistent reading and development experience for all who work on WordPress themes, plugins, applications, or the core application itself.

Remember: The purpose of coding standards is to make it so that source code looks as if it’s written by a single developer as it sets a level of expectations for contributing developers.

Indentation

As far as indentation is concerned, there’s nothing particularly new, revolutionary, or different as it relates to WordPress. Generally speaking, you’ll indent each time that you start a new block.

This means that:

Your functions will be indented within the class
Your conditionals and switch/cases and other blocks will be indented within their functions
Your loops will be indented within their functions, within their conditionals, and so on

If you’re used to writing code in C-style languages, then there’s nothing particularly new here, right?

An example of what this may look like is exactly this:

function foo( $arguments ) {

	if ( 0 < count( $arguments ) {

		foreach ( $arguments as $arg => $value ) {
			echo $value;
		}

	}

}

According to the Coding Standards:

Your indentation should always reflect logical structure. Use real tabs and not spaces, as this allows the most flexibility across clients.

The key take aways are that the beginning of lines should begin with tabs, and that the code should reflect a logical structure. Don’t overcomplicate or try to oversimplify things.

There’s one other nuance to white space within the WordPress Coding Standards: Tabs should be used at the beginning of the line, but spaces should be used everywhere else. For the most part, this is an easy rule to follow; however, in WordPress, you’re often going to be creating arrays to pass as arguments.

Ideally, we want each index of the array to line up so that readability is as high as possible but we often have a propensity to use tabs to make it easier to line them up, but this is actually a violation of the coding standards.

$args = array(
	'ID'           => 1,
	'post_title'   => 'The Title',
	'post_content' => 'The content'
);

As such, make sure that you only use tabs at the beginning of each line.

Space Usage

As it relates to WordPress, I’ve found that spaces have been used much more liberally than in other languages. I’m not saying this simply as an observation, as it was a personal adjustment I needed to make in coming both from .NET and Ruby.

That said, as with most other guidelines in the Codex, there’s nothing that’s particularly complex; however, there are some important distinctions that need to be remembered when writing code.

Spaces should be placed in the following places:

After commas
On both sides of logical operators (that is, ||, &&, and !)
On both sides of comparison operators (that is, <, >, ==, ===, etc.)
On both sides of assignment operators (namely =)
On both both sides of the opening and closing parenthesis of functions, conditionals, loops, and so on.
When a variable is being passed as an index of an array, but not when a literal value (such as a string or an integer)

Most of these are relatively straight forward, but in my experience I have found that the array rules tend to cause the most confusion among developers, so here’s a quick note of what’s considered correct and what’s not:

// Correct spacing...
$arr[ $x ] = 'foo';
$arr[0]    = 'bar';

// Incorrect spacing...
$arr[$x]  = 'bar';
$arr[ 0 ] = 'bar';

As you can see, it’s nothing terribly complicated but it’s a relatively easy convention to miss.

Trailing Spaces

This rule is likely the easiest standard to remember of them all. Simply put, there should be no trailing spaces left at the end of any line of code.

Depending on your IDE, you may have this filter built in; other times, you may need to install a plugin that will perform this action for you whenever you save the file. But whatever the case, it’s a relatively easy feature to integrate in whatever IDE you’re using.

Additionally, most editors – regardless of if it’s a glorified text editor or a full on IDE – you should have the ability to enable the display of tabs and spaces.

Viewing Tabs and Whitespace in Coda 2

Again, this is one of the simplest conventions to follow and it’s likely that your IDE or editor of choice has this feature or a plugin available that will allow you to automatically do this.

If not, you should be able to activate the ability to see tabs, spaces, carriage returns, and so on so that you can easily identify where the trailing spaces are.

Conclusion

Obviously, white space places a significant role in writing WordPress-based code. In this article, we’ve explored indentation, tabs, spaces, trailing spaces, and why and how to incorporate them into our projects.

In the next article, we’re going to continue talking about the subtleties of the WordPress Coding Standards by looking at brace style, regular expressions, and the nuances of using PHP tags through our WordPress code.

Integrating Multiple Choice Quizzes in WordPress – Creating the Backend

Rakhitha Nimesh — Wed, 12 Jun 2013 14:32:19 +0000

This entry is part 1 of 1 in the series Integrating Multiple Choice Quizzes in WordPress

Multiple choice questions are something that most of us have faced at least once in our life. We love them because we can provide correct answers by logically thinking about provided possibilities, even if we don’t exactly know the correct answer. Also answering takes less time which makes it so popular.

Creating a multiple choice quiz in WordPress can be a very exciting and profitable task. You can use it in your personal blog to attract more visitors, or you can create a premium section with advanced quizzes, or you can create quizzes focusing on popular certification exams. There are numerous possibilities for making it profitable.

This plugin won’t take you through to creating quizzes for building a business, but we have to start somewhere to get where we want to go. So this would be a good start for creating quizzes and making profits out of it.

So let’s get started.

Functionality of the Plugin

First we need to gather the requirements of the plugin before going to design or implementation. Basically, we should be able to create multiple choice quizzes and allow users to take the quizzes and get results.

So let’s take a look at the detailed requirements and components of our plugin:

The plugin should have a backend where we can insert questions and answers dynamically. Also it’s ideal to have quiz categories to group quizzes into specific sections.
Site admin should be able to configure the quizzes through a settings page.
Users should have a frontend where they can take a quiz.
Once a quiz is completed users should be able to get the scores and results.

This tutorial is going to be constructed as a two part series, where we develop the backend of the plugin in the first part, followed by the plugin frontend in the second part.

Planning the Plugin Backend

In this part we are going to focus on developing the backend of the plugin where we develop the required data for quizzes.

Usually there is a list of quizzes, each of them containing a specific list of questions. With this plugin we are not going to create quizzes. We will be creating individual questions and assigning them dynamically to quizzes when requested.

Now we can take time to identify the components required for implementing the backend as listed in the following section.

Questions need to be created in the backend with the answers. A custom post type will be the best solution for implementing the questions. So we are going to use a custom post type called wptuts_quiz.
Each question should have multiple answers and one correct answer. Fields for answers will be created inside a meta box in the custom post creation screen.
Questions will be categorized into various sub-topics hence we need a custom taxonomy called quiz_categories for the wptuts_quiz post type.
Then we need to validate the question creation process. We will be using client side jQuery validations when necessary in question creation.
Finally we need a plugin settings page to store the number of questions per quiz and the duration for a quiz.

Having identified the necessary WordPress components, we can directly move into implementing the backend of the quiz plugin.

Creating Questions

The question creation process consists of four main sections: defining custom post type, defining custom taxonomy, assigning custom fields, and validations. Each of these sections will be discussed with detailed code in the upcoming sections.

1. Creating the Questions Custom Post Type

We need the most basic form of custom post type for questions without any advanced configurations. The only thing we need to consider is the selection of the right field for the question.

The default post creation screen contains two fields for title and content. You can choose any of those fields for the question. I am going to choose concatenation of both title and content fields considering advanced possibilities.

We will be creating an object-oriented plugin instead of a functional plugin, so all of the necessary actions, shortcodes and initializations will be done inside the constructor. The following contains the code for implementing the wptuts_quiz post type.

class WP_Quiz {

	public $plugin_url;

	public function __construct() {

		$this->plugin_url = plugin_dir_url( __FILE__ );

		add_action( 'init', array( $this, 'wpq_add_custom_post_type' ) );

	}

	public function wpq_add_custom_post_type() {

		$labels = array(
			'name' => _x( 'Questions', 'wptuts_quiz' ),
			'menu_name' => _x( 'WPTuts Quiz', 'wptuts_quiz' ),
			'add_new' => _x( 'Add New ', 'wptuts_quiz' ),
			'add_new_item' => _x( 'Add New Question', 'wptuts_quiz' ),
			'new_item' => _x( 'New Question', 'wptuts_quiz' ),
			'all_items' => _x( 'All Questions', 'wptuts_quiz' ),
			'edit_item' => _x( 'Edit Question', 'wptuts_quiz' ),
			'view_item' => _x( 'View Question', 'wptuts_quiz' ),
			'search_items' => _x( 'Search Questions', 'wptuts_quiz' ),
			'not_found' => _x( 'No Questions Found', 'wptuts_quiz' ),
		);

		$args = array(
			'labels' => $labels,
			'hierarchical' => true,
			'description' => 'WP Tuts Quiz',
			'supports' => array( 'title', 'editor' ),
			'public' => true,
			'show_ui' => true,
			'show_in_menu' => true,
			'show_in_nav_menus' => true,
			'publicly_queryable' => true,
			'exclude_from_search' => false,
			'has_archive' => true,
			'query_var' => true,
			'can_export' => true,
			'rewrite' => true,
			'capability_type' => 'post'
		);

		register_post_type( 'wptuts_quiz', $args );
	}
}

We have enabled both title and editor fields in the custom post type to use for the question. Since the functions are located inside a class, we have to use $this in our WordPress actions, filters, and shortcodes to call the functions.

Apart from that all the parameters mentioned in the code are initialized with their default values.

2. Creating the Question Categories

In order to group questions into specific sections, we need something similar to default WordPress categories. Hence we will be using a custom taxonomy called quiz_categories. We need to call the custom taxonomy generation function on the init action as we did earlier. So the constructor of our plugin class needs to be updated with the following code.

add_action( 'init', array( $this,'wpq_create_taxonomies' ), 0 );

Then we can implement the wpq_create_taxonomies function on the wptuts_quiz post type as shown in the following code.

function wpq_create_taxonomies() {

	register_taxonomy(
		'quiz_categories',
		'wptuts_quiz',
		array(
			'labels' => array(
				'name' => 'Quiz Category',
				'add_new_item' => 'Add New Quiz Category',
				'new_item_name' => "New Quiz Category"
			),
			'show_ui' => true,
			'show_tagcloud' => false,
			'hierarchical' => true
		)
	);

}

I have used the default option parameters to create this custom taxonomy. Once the plugin is activated your custom post type and taxonomy will be displayed as shown in the following screen.

3. Creating the Question Answers

Next, we have to create multiple answers for each question. In this plugin the maximum number of answers per single question will be limited to five.

You can dynamically assign 1-5 answers for any question. Also we need to specify the correct answer from the provided list of answers. Since this data is associated with our questions, we can use a meta box with custom fields to generate the necessary fields.

As usual we need to update the constructor with the following code:

add_action( 'add_meta_boxes', array( $this,'wpq_quiz_meta_boxes' ) );

Consider the following code for the implementation of meta boxes with answers fields.

function wpq_quiz_meta_boxes() {
	add_meta_box( 'quiz-answers-info', 'Quiz Answers Info', array( $this, 'wpq_quiz_answers_info' ), 'wptuts_quiz', 'normal', 'high' );
}

function wpq_quiz_answers_info() {

	global $post;

	$question_answers = get_post_meta( $post->ID, '_question_answers', true );

	$question_answers = ( $question_answers == '' ) ? array( '', '', '', '', '' ) : json_decode( $question_answers );

	$question_correct_answer = trim( get_post_meta( $post->ID, '_question_correct_answer', true ) );

	$html = '<input type="hidden" name="question_box_nonce" value="' . wp_create_nonce( basename( __FILE__ ) ) . '" />';

	$html .= '<table class="form-table">';

	$html .= '<tr><th style=""><label for="Price">Correct Answer</label></th><td><select class="widefat" name="correct_answer" id="correct_answer" >';

	for ( $i = 1; $i <= 5; $i++ ) {

		if ( $question_correct_answer == $i ) {
			$html .= '<option value="' . $i . '" selected >Answer ' . $i . '</option>';
		}
		else {
			$html .= '<option value="' . $i . '">Answer ' . $i . '</option>';
		}

	}

	$html .= '</select></td></tr>';

	$index = 1;

	foreach ( $question_answers as $question_answer ) {

		$html .= '<tr><th style=""><label for="Price">Answer ' . $index . '</label></th>';
		$html .= '<td><textarea class="widefat" name="quiz_answer[]" id="quiz_answer' . $index . '" >' . esc_textarea( trim( $question_answer ) ) . '</textarea></td></tr>';

		$index++;

	}

	$html .= '</tr>';

	$html .= '</table>';

	echo $html;
}

4. Code Explanation

Answers of each question will be stored in a JSON encoded string in the post_meta table with the key _question_answers. So we access this field using the get_post_meta function to get the current values.
Then we get the correct answer of the question using a similar method. The correct answer will be stored as a string in the post_meta table with the key _question_correct_answer.
Finally, we create the HTML form, which contains the correct answer as a dropdown box and the possible answers as five text area fields.
All the existing values retrieved using the get_post_meta function will be assigned to the respective fields.

You should see something similar to the following screen, once you create the meta box.

Now we have all the data required for our quiz generation plugin. Next step is to save the question data into the database.

But we need some validations prior to that. So let’s move into validations.

Validating Question Creation

We don’t have complex validation rules at this stage in the question creation process. Therefore we are going to use client side jQuery validations before submission.

Here we need the admin_enqueue_scripts action to be included into the constructor of our plugin.

So update the constructor with following code before we get started.

add_action( 'admin_enqueue_scripts', array( $this, 'wpq_admin_scripts' ) );

Now look at the following code for including necessary script files for validation.

function wpq_admin_scripts() {

	wp_register_script( 'quiz-admin', plugins_url( 'js/quiz.js', __FILE__ ), array( 'jquery' ) );

	wp_enqueue_script( 'quiz-admin' );

}

Using wp_register_script and wp_enqueue_script, we have a plugin-specific JS file called quiz.js for handling validations. Validation will be done using the jQuery library and hence we have set the built-in jQuery library as a dependency for our plugin-specific JavaScript.

Having included the scripts, let’s implement the actual validations in the quiz.js file as shown in the following code.

jQuery(document).ready(function($) {

	$("#post-body-content").prepend('<div id="quiz_error" class="error" style="display:none" ></div>');

	$('#post').submit(function() {

		if ( $("#post_type").val() =='wptuts_quiz' ) {

			return wpq_validate_quizes();

		}

	});

});

First, we assign an empty div element to the post creation screen to display any errors. Then we can call a custom JS function on the post publish action by checking the correct post type using the #post_type hidden field value.

The following code contains the implementation of the wpq_validate_quizes function.

var wpq_validate_quizes = function() {

	var err = 0;

	$("#quiz_error").html("");

	$("#quiz_error").hide();

	if ( $("#title").val() == '' ) {

		$("#quiz_error").append("<p>Please enter Question Title.</p>");

		err++;

	}

	var correct_answer = $("#correct_answer").val();

	if ( $("#quiz_answer"+correct_answer).val() == "" ) {

		$("#quiz_error").append("<p>Correct answer cannot be empty.</p>");

		err++;

	}

	if ( err > 0 ) {

		$("#publish").removeClass("button-primary-disabled");

		$(".spinner").hide();

		$("#quiz_error").show();

		return false;

	}
	else {

		return true;

	}
};

Code Explanation

First we have to hide the error container and set its current error message to empty.
Then we check whether the title exists, as title is mandatory for questions.
Next we get the selected correct answer and check whether the answer field related to the correct answer is empty.
When validation errors are generated we display the errors in the specified error container and prevents the submission of the post.

The following image shows the post creation screen with custom validation messages.

Once the form is successfully validated without errors, we can move onto saving the question details to the database.

Saving Question Details

WordPress provides an action called save_post, which will be executed just after the post creation. We can define a custom function on the save_post action to save the custom field details into the database.

As usual update the constructor with the save_post action code.

add_action( 'save_post', array( $this, 'wpq_save_quizes' ) );

Implementation of the wpq_save_quizes function is given in the following code.

function wpq_save_quizes( $post_id ) {

	if ( ! wp_verify_nonce( $_POST['question_box_nonce'], basename( __FILE__ ) ) ) {

		return $post_id;

	}

	if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {

		return $post_id;

	}

	if ( 'wptuts_quiz' == $_POST['post_type'] && current_user_can( 'edit_post', $post_id ) ) {

		$question_answers = isset( $_POST['quiz_answer'] ) ? ( $_POST['quiz_answer'] ) : array();

		$filtered_answers = array();

		foreach ( $question_answers as $answer ) {

			array_push( $filtered_answers, sanitize_text_field( trim( $answer ) ) );

		}

		$question_answers = json_encode( $filtered_answers );

		$correct_answer = isset( $_POST['correct_answer'] ) ? sanitize_text_field( $_POST['correct_answer'] ) : "";

		update_post_meta( $post_id, "_question_answers", $question_answers );

		update_post_meta( $post_id, "_question_correct_answer", $correct_answer );

	}
	else {

		return $post_id;

	}
}

The post ID is passed automatically to this function. Initially we execute validations for nonce value and autosave. The most important thing before saving is the validation of post type.

If you omit the post type check, this code will be executed for all the post types in your WordPress installation including normal posts, which can result in inconsistent data.

Finally we get the values of our answers fields and correct answer field to be saved to the database using the update_post_meta function. All the custom fields details will be saved to the post_meta table.

Now we have completed the question creation process. Since we are using randomly generated quizzes, you might need lots of questions to see this plugin in action. So get ready by adding additional questions before we implement the quiz in the next part.

Quiz Settings Page

Even though it’s not mandatory, it’s ideal to have a settings page for our plugin so that the admin can customize according to their preferences.

So let’s implement a simple settings page to contain the quiz duration and number of questions per quiz. We need to implement the admin_menu action in the constructor.

add_action( 'admin_menu', array( $this, 'wpq_plugin_settings' ) );

function wpq_plugin_settings() {

	//create new top-level menu

	add_menu_page( 'WPTuts Quiz Settings', 'WPTuts Quiz Settings', 'administrator', 'quiz_settings', array( $this, 'wpq_display_settings' ) );

}

function wpq_display_settings() {

	$html = '<div class="wrap">
		<form method="post" name="options" action="options.php">
			<h2>Select Your Settings</h2>' . wp_nonce_field( 'update-options' ) . '

			<table width="100%" cellpadding="10" class="form-table">
				<tr>
					<td align="left" scope="row">
						<label>Number of Questions</label><input type="text" name="wpq_num_questions" value="' . get_option( 'wpq_num_questions' ) . '" />
					</td>
				</tr>
				<tr>
					<td align="left" scope="row">
						<label>Duration (Mins)</label><input type="text" name="wpq_duration" value="' . get_option( 'wpq_duration' ) . '" />
					</td>
				</tr>
			</table>

			<p class="submit">
				<input type="hidden" name="action" value="update" />
				<input type="hidden" name="page_options" value="wpq_num_questions,wpq_duration" />
				<input type="submit" name="Submit" value="Update" />
			</p>

		</form>
	</div>';

	echo $html;
}

We can use the add_menu_page function to add a settings page to the admin area. The wpq_display_settings function is used to implement the display elements of the settings page.

We have used two text fields for duration and questions per quiz. Form submission and data saving can be handled manually using custom code, but WordPress provides us a simplified method for updating options.

In this method you have to set the form action to the options.php file. Then you have to create a hidden field called action to contain the value of ‘update‘. Finally we need to have another hidden field called page_options to contain the names of the two text fields to be updated.

Make sure to use these built-in options update techniques in scenarios where the requirements for saving the fields are not complex.

Once the submit button is clicked, form details will be updated automatically without any custom code.

What’s Next

We have completed the backend of our quiz plugin. Now you can create questions and get ready for the next part where we will use these questions to dynamically generate quizzes.

Until then let me know the best possible way to implement a dynamic quiz on the frontend. Keep in mind that only one question will be displayed at a time. When the user requests a question, he can move to the next question.

Looking forward to your suggestions.

The WordPress Coding Standards: Single Quotes and Double Quotes

Tom McFarlin — Tue, 11 Jun 2013 12:49:50 +0000

This entry is part 3 of 4 in the series The WordPress Coding Standards

In this series, we’re taking a look at the WordPress PHP Coding Standards in order further understand how quality WordPress code should be written.

Sure, all of this is documented in the WordPress Coding Standards and it’s a site that every WordPress developer should have bookmarked and on hand when working on a theme, a plugin, or an application; however, if you’re just getting into WordPress development, then it’s important to understand the rationale as to why the conventions are the way they are.

In this article, we’re going to be taking a look at the use of single quotes and double quotes specifically when dealing with strings.

This may be the shortest, most straightforward article in the series, but it should cover some important nuances as it relates to working with single quotes, double quotes, and strings in WordPress.

Strings in PHP and Strings in WordPress

Before we actually discuss strings as they relate to WordPress, it’s important to understand how the PHP language interprets strings when they are single quoted or double quoted.

Single Quotes in PHP

First, the simplest, most straightforward way to define a string in PHP is to simply wrap it with single quotes (that is, the ‘ character).

As with most programming languages, there are ways to escape characters so that you’re able to write out a string literal. For example, if you wanted to write: “String’s in PHP are easy,” as a string, then you may do this:

'String\'s in PHP are easy.'

See? The backslashes will instruct PHP to write out the single quote rather than terminating the actual string.

The second thing to note is that if you have a variable, it will not be replaced when quoted in single quotes. For example, assume that you have a variable called $name and it contains the value “Envato”.

More specifically, in code, this would look like this:

$name = 'Envato'

If you were to embed the $name variable into another string, ‘Envato’ would not be replaced.

$name = 'Envato';
echo 'I\'m writing for $name. It\'s a lot of fun.';

This would just echo: I’m writing for $name. It’s a lot of fun.

Here is where double-quotes begin to come in handy.

Double Quotes in PHP

Straight from the PHP manual:

If the string is enclosed in double-quotes (“), PHP will interpret more escape sequences for special characters.

You can read more about the escape characters and other information in the PHP manual, but let’s say we were to rework some of the strings that we’ve defined above.

Our first example, that is the one with the escaped single quote, could now be defined like this:

"String's in PHP are easy."

Our second example could be taken a step further: Not only is the escape sequence no longer needed, but the variable will also be evaluated:

$name = 'Envato';
echo "I'm writing for $name. It's a lot of fun.";

The second line will literally echo: I’m writing for Envato. It’s a lot of fun.

So with this covered as an introduction, let’s talk about the specifics of strings in WordPress. The truth is, if you have a strong grasp on all of the above, there’s not much more to add other than a few one-off cases.

Single Quotes in WordPress

In keeping consistent with PHP coding conventions, the general rule of thumb to follow is to always use single quotes to define your strings.

Since much of the work done in WordPress also includes writing out markup within a PHP string, it’s best to place those strings in single quotes so that the attributes of the HTML element can be enclosed in double quotes.

For example:

$html = '<a href="http://wordpress.org" target="_blank">WordPress</a>';

Obviously, the above makes for a much cleaner reading experience than having to place several escape characters in to handle the double quotes, the slashes, and so on.

If you’re dealing with markup that needs to span multiple lines or where you’re creating several elements some of which are child elements of others, I always recommend indenting the code so that it reads like an HTML document would.

For example:

$name = 'Tom McFarlin';

$html = '<div id="container">';
	$html .= '<span>' . $name . '</span>';
$html .= </div><!-- /#container -->';

It’s important to note that this isn’t part of the WordPress Coding Standards – this convention is one that I simply find useful when it comes to maintaining code – however, recall that single quoted strings do not evaluate the value of a variable.

As such, it is important to note that, in this case, we’re using string concatenation to include the variable definition.

Double Quotes in WordPress

Just as with double quotes in PHP, it’s important to note that there are times in which it’s more preferable to use them especially when you need to evaluate a variable.

In using the example from the code above, we would adapt it as follows:

$name = 'Tom McFarlin';

$html = "<div id='container'>";
  $html .= "<span>$name</span>";
$html .= "</div><!-- /#container -->";

Notice that we replaced all of the single quotes with double quotes and that we no longer have to perform any string concatenation with the $name variable since it will be evaluated.

It’s also important to note that although it’s arguably more common to see double quotes applied to HTML attributes, single quotes work just fine as well, especially in scenarios like this.

But There Are Exceptions

When working with strings and various programming languages – namely HTML – it can get a little complicated in terms of how you’re nesting your code.

For example, say that you’re using PHP to write out JavaScript which is responsible for rendering some HTML. In this scenario, you’re going to be writing a lot of quotes.

Though it’s possible to simply alternate your quoting styles, this won’t work 100% of the time.

Even the Coding Standards state:

An exception to this is JavaScript, which sometimes requires double or single quotes.

Although there are times where you may not be able to do this, this reinforces the idea that we should strive to keep each programming language in its own file style and include them when and where necessary.

Are There Any Security Issues?

Yes, but WordPress makes them extremely easy to manage, and though this technically falls under data validation, it’s closely related to exactly what we’re discussing in this article.

The primary problem is that there are times where we may be dynamically writing out HTML attributes to our markup that have values we can’t anticipate. In cases like this, we need to be able to escape said data.

Fortunately, WordPress provides the esc_attr function. Simply put, this function will take an incoming string and encode the characters to make sure they are rendered to the browser properly.

Practically speaking, you would use it exactly like the Codex demonstrates:

echo '<input type="text" name="fname" value="' . esc_attr( $_POST['fname'] ) . '">';

For more information, be sure to review the Codex article.

Conclusion

So, as a general rule of thumb, you should stick with using single-quotes unless you’re going to be evaluating a string or you’re going to be returning and echo’ing HTML, JavaScript, or potentially even CSS back to the caller.

Just as the Coding Standards state:

You should almost never have to escape quotes in a string, because you can just alternate your quoting style.

So as you’re working with strings in your future work, keep these principles in mind and it could go along way to making sure that your strings are as clean, and easy to understand as possible within the context of your WordPress-based projects.

Making WordPress Apps Ready for Facebook

Kailan Wyatt — Fri, 07 Jun 2013 12:43:55 +0000

It is becoming increasingly popular for people to integrate their WordPress sites into Facebook applications and fan pages. Although this tutorial is not about how to make an integration, it will explain some smart code techniques that can be implemented for a Facebook-specific view.

Facebook and other websites have specific policies about what not to do on Facebook and this tutorial will show you just exactly how you can obey these policies.

Why Use This Technique? Avoid Getting Banned!

As lovely as it is to create a Facebook App using a WordPress site, many sites include advertising blocks from providers that Facebook does not allow.

Additionally, there is much talk on the net that Google Adsense does not allow the embedding of their ads on Facebook.

For the innocent web developer or blogger, it would be detrimental to get banned because of failure to adhere to either Google Adsense / Facebook policies; therefore, in order to avoid possible problems, the following technique can be implemented.

Facebook has provided a list of providers that they support: Advertising Providers on Facebook Platform

Writing the Function

For the purpose of this tip, we will assume that you are building an adsense-ready WordPress theme. Within the file functions.php, add the following function.

function is_facebook() {
	$url = $_SERVER['HTTP_REFERER'];
	$parse = parse_url( $url );
	$host = $parse['host'];
	if ( 'apps.facebook.com' == $host ) {
		return true;
	}
	else {
		return false;
	}
}

The line $url = $_SERVER['HTTP_REFERER']; sets a variable of the Facebook App to the address that the WordPress site is being iframed in. For example: http://apps.facebook.com/my-app-name/
$parse = parse_url( $url ); creates an array of all components used in the Facebook App address.
$host = $parse['host']; This line gets the host being used, which in this case is apps.facebook.com
The next lines check to see if the host is from a Facebook App and returns a Boolean.

Using the Function

In places where you would like to display an Adsense block, you can write the following:

if ( is_facebook() ) {
	// Display nothing or display AD from Facebook Ad Provider
}
else {
	// Display my Adsense Ads
}

Other Uses of the Function

Change logo / images on Facebook Apps
Create Facebook specific layouts
Use Facebook comments while viewing on Facebook

A neat trick with this function is to call different template parts. The snippet below, shows you how you can call a different header file header-facebook.php by using the function.

if ( is_facebook() ) {
	get_header( 'facebook' );
}
else {
	get_header();
}

Creating a Shortcode

Still assuming that you are working on a theme, open the functions.php file and add the following:

add_shortcode( 'is_fb', 'wp_if_fb' );
function wp_if_fb( $atts, $content = null ) {
	if ( is_facebook() ) {
		return $content;
	}
}

add_shortcode( 'not_fb', 'wp_not_fb' );
function wp_not_fb( $atts, $content = null ) {
	if ( ! is_facebook() ) {
		return $content;
	}
}

The first line creates a shortcode is_fb with a call back function wp_if_fb. Content passed in the shortcode will be displayed only if the WordPress site is wrapped in a Facebook iFrame.

The second add_shortcode function is used to display items in a post not currently viewed via Facebook.

How to Use the Shortcode

Within any textarea that the shortcode filter is applied to, you can use the previously created shortcode there. Below is an example of how to use the snippet.

[is_fb]This is my text that will show up on Facebook[/is_fb]

[not_fb]This test will be displayed outside of Facebook[/not_fb]

A more practical example is a welcome message in an about page.

For example:

I would like to welcome you to my [not_fb]Website Portal[/not_fb][is_fb]Facebook Application[/is_fb]

To learn more about creating shortcodes, visit this link: Shortcode API

Conclusion

Again, I can not stress enough about the importance of adhering to Google / Facebook’s policies. For guest bloggers that are engaged in revenue sharing sites, it is important to know that their Google Adsense accounts are not at risk of being banned. Therefore, if measures were put in place by using our function, we can minimize the risk.

For Designers, the function we have created would be a perfect solution to creating a Facebook specific design in their themes. Such a design can make the WordPress site look like a well designed Facebook App by removing aspects that would otherwise make it seem more like a website. Like hiding header and footers to display page only, would be great for a simple promotional page tab.

Finally, the Developers can take advantage of the plugin and use it in their WordPress plugins. Developers can use the snippet for custom registration and login scripts, advertisement plugins and so much more.

The WordPress Coding Standards: Naming Conventions and Function Arguments

Tom McFarlin — Thu, 06 Jun 2013 13:27:58 +0000

This entry is part 2 of 4 in the series The WordPress Coding Standards

In this series, we’re taking a deep dive into the WordPress Coding Standards – specifically, the PHP coding standards – in order to evangelize and understand how quality WordPress code should be written.

Despite the fact that this is documented within the WordPress Developer Handbook, I think there’s something to be said for understanding the rationale behind why some things are the way that they are.

Remember: Our ultimate goal is to make sure that we’re writing code that conforms to the coding standards so that we, along with other developers, are able to more easily read, understand, and maintain code for themes, plugins, and applications built on top of WordPress.

In this post, we’re going to be taking a look at how to handle naming conventions and function arguments.

Naming Conventions

Before spending any time elaborating on the points outlined in the coding standards, it’s important to understand the role that naming conventions play in writing code regardless of what platform with which you’re working.

Ultimately, naming conventions – regardless of if they are for classes, functions, variables, attributes, or arguments – should help to explicate the purpose that they serve.

By that, I mean that class names should typically be nouns, functions should typically be verbs, and variables, attributes, and arguments should explain the purpose that they serve within the context of the class or function in which they are to be defined. It’s all about making the code as readable as possible.

Just as the Coding Standards state:

Don’t abbreviate variable names un-necessarily; let the code be unambiguous and self-documenting.

This is a good rule of thumb regardless of what part of the code it is on which you’re working.

Class Names

When it comes to working with WordPress, you’re not likely to encounter classes unless you’re doing one of two things:

Writing a custom library to work alongside a theme or application
Writing an OOP-based plugin

If you’re simply working on the theme, you’re more likely to be working with a set of functions – we’ll be talking about those momentarily.

But for those who are working with plugins or their own libraries, it’s important to remember that classes should typically be nouns – they should represent the purpose that they encapsulate and they should ideally do one thing and do it well.

For example, if you have a class called Local_File_Operations then it may be responsible for reading and writing files. It shouldn’t be responsible for reading and writing files as well as, say, retrieving remote files.

According to the WordPress Coding Standards, classes should follow the following conventions:

Class names should use capitalized words separated by underscores.
Any acronyms should be all upper case.

Simple, right?

Practically speaking, this would look like the following:

class Local_File_Operations {}
class Remote_File_Operations {}
class HTTP_Request {}
class SQL_Manager {}

To reiterate: classes should also be nouns and should describe the single purpose they serve.

Function Names

As mentioned earlier, if classes are nouns that ideally represent a single idea or single purpose, then their methods should be the actions that they are able to take. As such, they should be verbs – they should indicate what action will be taken whenever they are called.

Furthermore, the arguments that they accept should also factor into the name of the function. For example, if a function is responsible for opening a file, then its parameter should be a file name. Since our goal should make it as easy as possible to read code, then it should read something like “have the local file manager read the file having the following file name.”

In code, this may look something like this:

// The class definition
class Local_File_Manager {

	public function open_file( $filename ) {
		// Function implementation
	}

}

// How we'd use this code
$file_manager = new Local_File_Manager();
$file_manager->open_file( 'foo.txt' );

Of course, this still doesn’t cover how functions should be written within the context of WordPress development. The Coding Standards state:

Use lowercase letters in variable, action, and function names (never camelCase). Separate words via underscores. Don’t abbreviate variable names un-necessarily; let the code be unambiguous and self-documenting.

The first part of of the convention is easy enough to understand; however, I think developers have a propensity to take shortcuts when they are able. “Ah,” we think, “$str makes sense here, and $number make sense here.”

Of course, there are always worse – some developers resort to using single characters for their variable names (which is generally only acceptable within loops.)

Just as the Coding Standards state: Don’t abbreviate variable names un-necessarily. Let the code be unambiguous and self-documenting.

Now, the truth is, code can only be unambiguous to a point. After all, that’s why it’s called code, right? This is why I think code comments should be used liberally.

Anyway, the bottom line is to lower case your method names, avoid all camel casing, separate by spacing, and be as specific as possible when naming your variables.

Variable Names

Variable names actually aren’t much different from function names other than they represent a single value or a reference to a particular object. The naming conventions still follow what you’d expect:

Lower case (versus camelCase)
Separate spaces with underscores

One other convention that some developers use is what’s known as Hungarian Notation which is where the type of value the variable stores is prefixed in front of the variable.

For example:

Strings will often be represented as $str_firstname
Numbers will be written as $i_tax or $num_tax
Arrays may be written as $arr_range
…and so on

Honestly, the coding standards say nothing about this. On one hand, I do think that this makes for cleaner code in the overall scope of code, but there are a lot of developers who dislike Hungarian Notation.

Since the coding conventions say nothing about them, I’m hesitant to recommend them as I want to stay as close to standards as possible. As such, I have to recommend that it’s best to follow the coding standards.

File Names

In keeping consistent with the theme of making our code as readable and self-documenting as possible, it makes sense that we pull this through our source code all the way to the files that we’re going to make up our theme, plugin, or application.

According to the Coding Standards:

Files should be named descriptively using lowercase letters. Hyphens should separate words.

In keeping consistent with our previous example, let’s say that we’re working with Local_File_Operations then the file would be named class-local-file-operations.php.

Easy enough.

Next, if you’re working on a plugin called Instagram_Foo then the file should be named instagram-foo.php; however, it is worth noting that if you use some type of advanced methods for developing your plugins such as keeping the plugin class file in its own file and then loading it using it another file, then your file structure may be:

class-instagram-foo.php
instagram-foo.php

Where instagram-foo.php is responsible for loading the class-instagram-foo.php. Of course, this only makes sense if you’re using OOP when writing your WordPress plugins.

Function Arguments

When it comes to passing function arguments, it’s important to remember that if function names describe the actions that are being taken by the class, then the argument should represent on what the function is actually operating.

From the Coding Standards:

Prefer string values to just true and false when calling functions.

Since boolean values can be unclear when passing values into a function, it makes it difficult to ascertain exactly what the function is doing.

For example, let’s use the above example in a slightly different manner:

// The class definition
class Local_File_Manager {

	public function manage_file( $filename, true ) {

		if ( true ) {
			// Open the file
		} else {
			// Delete the file
		}

	}

}

// How we'd use this code
$file_manager = new Local_File_Manager();
$file_manager->manage_file( 'foo.txt', true );

Is more difficult to understand than, say, something like this:

// The class definition
class Local_File_Manager {

	public function open_file( $filename ) {
		// open the file
	}

	public function delete_file( $filename ) {
		// delete the file
	}

}

// How we'd use this code
$file_manager = new Local_File_Manager();
$file_manager->open_file( 'foo.txt' );
$file_manager->delete_file( 'foo.txt' );

On top of that, remember that arguments being passed into functions are still variables in and of themselves so they are subject to the variable naming conventions that we’ve detailed above.

Conclusion

We’ve taken an extended look at Naming Conventions and Function arguments in the Coding Standards. Hopefully this has helped to provide not only a guide for how to improve certain aspects of your WordPress code, but also to explain the rationale behind some of the practices.

In the next article, we’re going to take a look at the significance of single quotes and double quotes within the context of working with strings in WordPress development.

There is a difference into how they are interpreted by PHP and there are conditions in which you should use one over the other and we’ll be reviewing that in the next article.

Building a WordPress-Friendly API Wrapper: Foundations

Japh Thomson — Wed, 05 Jun 2013 13:13:09 +0000

This entry is part 1 of 1 in the series Building a WordPress-Friendly API Wrapper

When building a web site or web application, it’s a pretty common requirement that you might need to pull in data from third-party site or application. If that site or application has an API, this is an excellent way to obtain the data needed. So, let’s take a look at how to do this with WordPress.

What Is an API?

Before we get into the nitty gritty, let’s make sure we’re all up to speed with a couple of things, starting with what an API is.

For the purposes of this tutorial, when we say “API” (application programming interface) we specifically mean what Wikipedia classes as a “Web API“:

A server-side web API is a programmatic interface to a defined request-response message system, typically expressed in JSON or XML, which is exposed via the web — most commonly by means of an HTTP-based web server.

To put it more simply: an API is a way for one application to ask another application for predefined information in (most often) JSON or XML format, over a standard web URL.

Got it? Ok, next…

What Is a “Wrapper”?

Making a request to an API can involve a number of steps, and you may want to add in extra steps such as error checking, caching, validating, etc.

Wikipedia defines a Wrapper function as follows:

A wrapper function is a function in a computer program whose main purpose is to call a second function with little or no additional computation. This is also known as method delegation. Wrapper functions can be used for a number of purposes.

That definition may make it sound a little like wrappers are just redundant code, but they’re actually far from it.

Important Considerations

Creating a wrapper for an API allows us to be friendly to everyone. Let me explain:

APIs often have a “rate limit”, which is the number of times and frequency at which you can contact them. Contacting an API more than the rate limit specifies can get you blocked, and for information that doesn’t change that regularly, it creates unnecessary load on the API. By creating a wrapper, we can implement our own caching so we contact the API less frequently.
Further to this, if we make a request to an API with information that’s incorrectly formatted or incomplete, it’s a wasted request. We should make sure the request we send is complete, and formatted correctly, as best we can before we send it.
Sometimes an API may send information back that’s not quite formatted in the simplest way for us to use. Having a layer in between the developer and the API allows the chance to massage the data as needed before the developer gets it.
Developers also shouldn’t have to repeat themselves more than necessary. If we bundle all the steps involved in making an API call up into a wrapper, this simplifies development using the API in question.

Wrappers make dealing with APIs developer-friendly, and API-friendly.

So the particular things we’re going to get our API to handle are:

Making a call to the API when the developer requests information
Checking to ensure valid data is sent to the API
Checking if the API returned an error rather than useful data, and dealing with it accordingly
Caching responses from the API so that if the same request is made in a short space of time, we don’t have to contact the API
Adjusting the returned data for simplified usage

We’ll also be doing these things in a WordPress-friendly way, such as utilising transients for caching, and wp_remote_request for sending the API requests.

Building the Foundation

The API we’re going to be using for this tutorial is the Envato Marketplace API. This API provides information on the items and users on the Envato Marketplaces, such as ThemeForest, CodeCanyon, and others.

We’ll be basing our development around Public Sets, seen in the Envato Marketplace API documentation. Also, note the TTL (time to live) column, which is essentially the “rate limit” for this API. As the data only changes with this frequency, there’s no point requesting any given set more often than the TTL specified.

So let’s begin building the base class for communicating with this API.

1. File Structure

Because this will eventually be inside an example plugin, which we’ll get to later, let’s create that file structure and build the API wrapper inside.

Our plugin will be showing the results of the “random-new-files” API set, so we’ll call it “Wptuts+ Random New”. So inside your wp-content/plugins/ directory, go ahead and create a directory called wptuts-random-new.

Now inside that directory, make a new directory called envato-api-wrapper, and a file inside that called class-envato-api-wrapper.php. This whole directory will then be able to be copied into other projects that need to use this API in future too.

2. Class and Basics

Open the *class-envato-api-wrapper.php file, and let’s begin.

First, let’s define our class:

<?php
class Envato_Marketplace_API {

    // All the things

}

We’re also going to need a simple way to test this wrapper as we build it, without having to load all of WordPress. So what I’ve done, is just create an index.php file in the envato-api-wrapper directory, with the following content:

<?php
// We want to see errors during debugging
error_reporting(E_ALL);
ini_set('display_errors', '1');

// We need to use some WordPress functions
require( '../../../../wp-load.php' );

// And we need our wrapper!
require( 'class-envato-api-wrapper.php' );

// Initialise our wrapper
$envato_api = new Envato_Marketplace_API();

Now you should be able to browse to http://localhost/wp-content/plugins/wptuts-random-new/envato-api-wrapper/ (replace “localhost” with your own development environment). You shouldn’t see anything yet though, because wrapper doesn’t do anything yet. If you see an error though, double-check the code.

Note: don’t forget to remove this file, or blank it out, before deploying to production!

3. Where to Send Requests

The first thing you’re going to need before making a request to an API, is the base URL to use. This URL will then have various information added to it before sending the request.

In the case of the Envato Marketplace API, we’ll use the following URL:


http://marketplace.envato.com/api/edge/set.json

In this URL there are two main variable bits of information: edgde and set.

The position of edgde represents the version of the API we want to use, and in this specifically the most current version. It will be the same in all requests, however if something changes and we wanted to use an older version, we could swap it out for v3 instead for example.

The position of set represents the actual data set we’re requesting. The word “set” is a placeholder, and we’ll replace it with the relevant details when making a specific request.

Let’s add a property of $api_url to our class with this value:

<?php
class Envato_Marketplace_API {

    protected $api_url = 'http://marketplace.envato.com/api/edge/set.json';

}

Note that we’ve indicated this property is ‘protected‘. We’ve done this because we don’t want the URL to be changed directly by other code outside of our wrapper.

4. Making a Request

Before we try making an specific request, we’ll add a generic method to our class that will handle making any request. We’ll call it remote_request, and all it will need is a URL to send the request to.

protected function remote_request( $url ) {

    // Firstly, if the URL is empty, don't send a request
    if ( empty( $url ) ) {
        return false;
    }

    // Make the request
    $request = wp_remote_request( $url );

    // Check that WordPress was able to send the request, otherwise error
    if ( is_wp_error( $request ) ) {
        echo $request->get_error_message();
        return false;
    }

    // Decode the response so we can use it
    $data = json_decode( $request['body'] );

    if ( $request['response']['code'] == 200 ) {
        return $data;
    }
    else {
        return false;
    }

}

Note that again we’ve indicated that this method is ‘protected‘, to prevent it being called directly from outside our class.

Now to be able to test that the request is working, we’ll add our first API method. In this case, we’ll go with the random-new-files set, which is the one we’ll use later in our example plugin.

Add the following method to our class:

public function random_new_files( $marketplace ) {

    // Create a URL for this request by replacing the 'set' placeholder with the set and any required parameters. In this case, the slug of an Envato marketplace
    $url = preg_replace( '/set/i', 'random-new-files:' . $marketplace, $this->api_url );

    // Send a request to the API
    $results = $this->remote_request( $url );

    return $results;

}

To test this new method, and by extension the API request method, add the following line to our debugging index.php file:

echo '<pre>' . print_r( $envato_api->random_new_files( 'themeforest' ), true ) . '</pre>';

Now you should get output in your browser similar to this:

stdClass Object
(
    [random-new-files] => Array
        (
            [0] => stdClass Object
                (
                    [id] => 4860464
                    [item] => Empire - Business, Portfolio HTML 5 Template
                    [url] => http://themeforest.net/item/empire-business-portfolio-html-5-template/4860464
                    [user] => designthemes
                    [thumbnail] => http://1.s3.envato.com/files/57931279/thumb-html.png
                    [sales] => 0
                    [rating] => 0.0
                    [cost] => 15.00
                )

                ...

            [9] => stdClass Object
                (
                    [id] => 4852371
                    [item] => eplie | Mobile HTML/Css Portfolio Template
                    [url] => http://themeforest.net/item/eplie-mobile-htmlcss-portfolio-template/4852371
                    [user] => cosmincotor
                    [thumbnail] => http://1.s3.envato.com/files/57831617/thumbnail.png
                    [sales] => 3
                    [rating] => 0.0
                    [cost] => 8.00
                )

        )

)

Assuming you saw something like the above, that means it’s working and you’ve gotten data back from the API. Success!

Next: Caching, Error Handling, and a Widget

Now we’ve gotten the basis of the wrapper done, things are under way. In the next part, we’ll finish off the wrapper and build a widget that utilises it.

Also, keep in mind that while this wrapper is being built for the Envato Marketplace API, the same concept (and a lot of the same code so far) can be used to create a wrapper for any RESTful API.

Let us know in the comments what ideas you have for working with APIs and WordPress.

The WordPress Coding Standards: An Introduction

Tom McFarlin — Tue, 04 Jun 2013 14:09:53 +0000

This entry is part 1 of 4 in the series The WordPress Coding Standards

When it comes to building WordPress-based products, we’re somewhat cursed (or blessed, depending on how you see it), with a double-edged sword: Because WordPress is written in PHP, it’s relatively easy to get WordPress – or the project itself – to do whatever it is we want to do all the while avoiding best practices.

But this raises the question: What’s the point of an API or formal coding standards if we’re simply going to ignore them?

We’ve written quite a bit about the WordPress APIs in previous articles, and we’ve touched on the WordPress Coding Standards, but we’ve never really taken a deep dive into the coding standards, understanding each aspect of them, and why they matter.

So in this series, we’re going to be doing just that.

Why Bother With Coding Standards?

Before taking a look at everything that we’re going to be covering, I think it’s important to understand why coding standards even matter.

WordPress is widely used by a lot of people using a lot of sites. There’s a lot of code being employed out there that’s all built on top of the core application. This means that there are developers and designers who are working to maintain those code bases.

The challenge comes when the person who didn’t originally write the code is stuck with improving, managing, and fixing bugs for the project. Let’s say that the first person didn’t follow the coding standards, but the person who is now maintaining the code is used to following best practices.

They now have to deal with code that looks nothing like what WordPress code should look like.

And that’s really the crux of the matter: The code that makes up our themes, our plugins, and in our applications should ideally look like a single developer wrote the code.

That’s what coding standards enforce.

Unfortunately, standards are either ignored or they aren’t evangelized enough despite the fact they are well-documented. That’s where this series of articles comes into play: We’re going to be looking at each of the standards in-depth to evangelize, to understand, and to encourage one another to begin doing a better job.

A Look at the Coding Standards

This series is going to include seven article in addition to this introductory piece.

Here’s where we are headed with this particular series:

Naming Conventions and Function Arguments – We’ll take a look at how we should name our variables, methods, and classes such that they are clear, easy to understand, and follow for ourselves and other developers.
The Use of Single Quotes and Double Quotes – Single quotes and double-quotes result in different behavior in PHP and there is a time and a place for when to use which in WordPress. In this article, we’ll take a look at examples of each and the rationale behind what we’re doing.
Indentation, Space Usage, and Trailing Spaces – White space places a big part in writing WordPress-based code. This article is going to explore the reasons why indentation and space matter as well as when to use tabs and when to use spaces.
Brace Style, Regular Expressions, and PHP Tags – Different C-style languages use different syntax. This article will examine the proper way to place braces in your WordPress-based code. We’re also going to examine the proper way to include regular expressions, as well as some of the gotchas and best practices as it relates to using PHP tags.
The Ternary Operator and Yoda Conditions – Conditional statements are a corner stone of programming and they are used liberally throughout WordPress. PHP offers a shortcut for if/else statements, and WordPress opts to evaluate conditionals differently than what other languages often support. Here, we’ll take a look at all of the above.
Database Queries and Formatting SQL Queries – There’s a full API for running queries against the WordPress database, but there are also ways to run raw SQL. If you ever need to go that route, there’s a right way to do it. This article will take a look at exactly that.
Bringing It All Together – Finally, we’re going to summarize everything that we’ve discussed throughout the series to make sure that we’re all on the same page, and to urge us to move forward with doing a better job of adhering to the standards.

Conclusion

When it comes to blogging, it’s often assumed that the author is an expert in the topic at hand, but the truth is although I firmly believe that we should follow the coding standards and that I try to adhere to them to the best of my ability, I’m learning things each week.

I’ve violated the coding standards plenty of times, and I’m sure some of you have, as well.

The point of this series is to walk through the standards together so that we may all come out as better developers once we’re done.

Quick Tip: Add Shortlinks to Custom Post Types

Stephen Harris — Mon, 03 Jun 2013 12:43:36 +0000

If you use any form of social media, and in particular Twitter, then you have almost certainly come across ‘shortlinks’ – shortened URLs which act as a label, pointing to a particular page but disguising its lengthier URL. They’ve been around for over a decade now, but their use really took off with URL shortening services which provided click-through statistics, and character limits on tweets.

WordPress has its own built in ‘shortlink’ – which, by default, probably isn’t very deserving of the name. These are the www.yoursite.com?p=1 links which point to a single post and you can grab them from the ‘Get Shortlink’ button on your post’s edit screen.

There’s a good reason for this: WordPress did not want to impose any particular third-party service for URL-shortening, and beneath the default www.yoursite.com?p=1 shortlinks lies an API which allows you to replace it with a more substantially shortened URL from another service – or perhaps even your own.

But WordPress’ shortlinks only appear on posts – not pages, or any other post type. In this quick tip I’ll be showing you how to rectify this. (And in a similar way you can change the default shortlink entirely by one from a URL shortener service).

Cracking open the source code and locating the wp_get_shortlink() function (see Codex) we find the following:

function wp_get_shortlink($id = 0, $context = 'post', $allow_slugs = true) {

    // Allow plugins to short-circuit this function.
    $shortlink = apply_filters('pre_get_shortlink', false, $id, $context, $allow_slugs);
    if ( false !== $shortlink )
        return $shortlink;

        ...

The hook pre_get_shortlink, therefore, allows us to by-pass WordPress’ default handling of shortlinks. To do that our plug-in needs only to hook onto that filter and return anything other than ‘false’.

/**
 * A function which adds a shortlinks button for 'portfolio' post type
 */
function wptuts_shortlinks_for_portfolio( $shortlink, $id, $context ) {

	// Context can be post/blog/meta ID or query
	$post_id = 0;

	if ( 'query' == $context && is_singular( 'portfolio' ) ) {

		// If context is query use current queried object for ID
		$post_id = get_queried_object_id();

	}
	elseif ( 'post' == $context ) {

		// If context is post use the passed $id
		$post_id = $id;

	}

	// Only do something if of portfolio post type
	if ( 'portfolio' == get_post_type( $post_id ) ) {
		$shortlink = home_url( '?p=' . $post_id );
	}

	return $shortlink;
}
add_filter( 'pre_get_shortlink', 'wptuts_shortlinks_for_portfolio', 10, 3 );

Note that if you do not want to change the shortlink (for instance, it’s the wrong post type) it’s important to return $shortlink (the filtered value that was passed to us by the hook) and not ‘false’ – since other plug-ins may have already changed $shortlink – and by returning false you would be overriding them.