Adding filters in WordPress is also a common practice. Combining this with the Options API can allow for, for example, the ability to change an option when in preview mode without committing to the change.

In the “Magazine” template in Canvas by WooThemes, for example, WooTumblog “image” and “video” posts are aware when they are present in the magazine-style grid. This is an example of filtering the Options API.

How do I use this?

Filtering the Options API is as easy as compiling any other filter. The filter hook is as follows: “option_optionname” (replace “optionname” with the name of the option you want to filter).

That filter is applied after the database lookup. What about before that even happens?

It is possible to short-circuit an option’s value using a second filter that has been made available. This means it’s possible to set a custom value, via a filter, for an option, bypassing the database lookup. My thoughts are packed with ideas for where to use this filter!

To short-circuit an option called, for example, “testoption”, you’d add the following code to your functions.php file:

add_filter( 'pre_option_testoption', 'matty_shortcircuit_options' );

function matty_shortcircuit_options ( $default ) {
	$value = 'this is a short-circuited option';
	return $value;
} // End matty_shortcircuit_options()

Using the “testoption” example again, this is how you’d override the value after it’s been retrieved from the database:

add_filter( 'option_testoption', 'matty_override_options' );

function matty_override_options ( $value ) {
	$value = 'this is an overridden option';

	// To override based on a condition, do this.
	if ( $value == 'test' ) {
		$value = 'this is an overridden option, based on a condition.';
	}

	return $value;
} // End matty_override_options()

This is just, however, a starting point as to how to do this. The possibilities are virtually limitless as to what is possible here and how to apply this in your projects.

Over the past few years (I’d say, since about 2008), I’ve decided to approach tasks day to day from a different angle. How can we say that a task is “impossible” if we haven’t even yet attempted it?

This is quite a common occurrence in web development… developers looking at a task, attempting to analyze it, getting “stuck” at one point and then moving on, deeming it “impossible”. Why does it have to, all of a sudden, be “impossible”, if you haven’t even attempted it yet? Why settle for the “shortcut” when you could just sit down and develop it how you envision it in the first place?

It’s not about it being “impossible”… you just haven’t found the correct pieces yet, or how they fit together.

As a small example to illustrate how this approach sucks and how it could be improved with a simple re-thinking process, lets take a look at a real-world scenario I experienced last year.

During the development of our “Editorial” theme at WooThemes, we wanted to add functionality to provide the administrator with more control over how many columns their content should be laid out in. This, at first glance, seems quite straight forward. A simple PHP script to cut and re-arrange the words at certain points would do this.

What if the author wants to control where the content is cut off? What if they want virtually infinite possible columns? Well, a shortcode would do this, right?

What if they switch themes? Their content would look ugly and be riddled with a bunch of shortcodes that aren’t in use anymore. In a context like this, where the content is everything, we couldn’t have that.

This is where we got down to the drawing board and found the solution that stands to date. A simple button that adds an HTML comment into the author’s content. We then use a WordPress filter (and regular expression) to convert the HTML comments into semantic HTML tags on the frontend, keeping count of how many columns are being generated and adjusting the layout accordingly. If the administrator decides to switch themes, the HTML comments won’t affect the display of the content, nor the functionality of the WordPress admin. The button itself, as well as how the HTML comments are displayed in the WordPress admin, echoes how WordPress itself handles similar functionality, integrating seamlessly into the authoring experience.

To illustrate how this relates to the “impossible”, many would settle for the shortcode option, as it is the most direct and “obvious” choice, without taking into account the ramifications thereof.

We’ve taken this same approach on many other pieces of functionality within themes and functionality developed at WooThemes. I’ve made this concept a part of my day to day approach to things as well.

To sum it up in a sentence, I’d say, “don’t assume something is ‘impossible’ until you’ve tried it. You never know… you may just get a better result”.

We thought it’d be a cool idea to showcase what the recruits of 2012 have compiled.

Check out what the 2012 recruits put together:

• mtricam
• genevievedavids
• augustinemutale
• margofortune
• suzannesmith42
• justinejooste
• ricardoglittle
• thembil
• nathanieldicks
• gershwin21
• cyrilmphanga

Pretty cool, right?

These are the slides from yesterday’s presentation at the GROW Academy. Share your thoughts in the comments below.

The GROW Academy is an initiative to educate and empower the youth of today through technology. The Bootcamp session covers everything from social media and setting up e-mail, all the way through to search engine optimisation and an internet super-user course, for those who wish to continue on with more advanced studies. The GROW website’s “About” page (built on Canvas and Canvas BuddyPress by WooThemes) has a detailed explanation of the initiative and it’s founding partners.

This year, Jeff and I will be making some exciting additions to our presentation. While code, to some, can seem dry and boring, I can assure you that there’s nothing dry or boring about our presentation. We had such a blast at last year’s Bootcamp and are really looking forward to getting into some code with this year’s recruits.

If you’re keen to get involved with GROW, I’d encourage you to contact the GROW Academy and see how you can help out.

Remember: it’s all easy, and there’s no such thing as a stupid question.

The Transients API, while similar to the WordPress options API, has the addition of an expiry time. The API is used to store data in the database for a fix amount of time, at which point it is deleted and would need to be re-added, if one requires the data again. The WordPress Codex explains the Transients API as:

…very similar to the Options API but with the added feature of an expiration time, which simplifies the process of using the wp_options database table to store cached information.

From a technical standpoint, transients are also sped up by caching plugins, which store the data in memory, rather than in the database, making for a faster lookup.

Getting started

Using transients is easier than you might think. The first thing to note is that there are two types of transients; conventional (only on the specified site within a WordPress multisite installation) and “site” (across the entire WordPress multisite installation). They interact in the same way though.

The Transients API has 3 core functions; set_transient(), get_transient() and delete_transient(). They function in the same way as add_option(), get_option() and delete_option() do, so they should be familiar.

Brief function analysis

set_transient()

Stores data in a transient.

The parameters are:

1. The transient key (the name of the transient to store the data in)
2. The value (the data to store)
3. The expiration (the time expiration, in seconds, from the time of storage – one day would be 60 * 60 * 24)

get_transient()

Retrieve the transient data, if it’s available.

The parameters are:

1. The transient key (the name of the transient the data is stored in)

delete_transient()

Force the expiry/removal of a specified transient.

The parameters are:

1. The transient key (the name of the transient the data is stored in)

The Transients API in use

To use the Transients API, the process is straight forward. Check if the transient is available. If it isn’t, get the data (this could be anything from a simple line of text -which may not be too practical- to an advanced and resource-intensive database query, which you may not want to run every time your website is loaded) and assign it to the transient. Assign the data to a variable and return it for use in your code.

In code, this may look like the following:

<?php
	$transient_key = 'my-transient-key';
	$data = get_transient( $transient_key );
	if ( $data == '' ) {
		$data = get_posts( array( 'posts_per_page' => -1 ) );
		set_transient( $transient_key, $data, 60 * 60 * 24 );
	}

	// You would then carry on using $data in your code.
?>

An example of when WordPress itself uses the Transients API is during checks for updates of themes, plugins and WordPress itself. These checks don’t in fact happen each time you visit the “Updates” dashboard screen, but periodically based on a transient of stored information about the themes and plugins you have in your installation.

Where and when to use the Transients API

Usage of this API is vast and varied. Essentially, the Transients API can be seen as a form of caching system with an expiry time. Therefore, you may want to cache data (for example, from an RSS feed or API request) for a few hours or days, or you could cache something for a few seconds while a user is busy on your website (to make their experience that little bit faster). With such simple implementation, the usage possibilities are limited only by one’s imagination and a coding project’s requirements.

Now that you know about the Transients API, I’m certain you’ll start using it more often to speed up your projects. This API, while seemingly so small and simple, is incredibly powerful and can transform bloated code into streamlined genius.

Having given this some thought, the “Uncategorized” category doesn’t really seem correct in that the term is a category in itself. It’s almost a full paradox to say that a post is “uncategorized”, meanwhile it is in fact in a category.

Upon removing the relationship entirely between the “Uncategorized” category and a specific post, the post worked as expected with no issues. By default, a post is assigned to the category set as the default category in the WordPress settings screens within the WordPress admin. Therefore, while it is possible to assign a new default category and delete the “Uncategorized” category, the question is more, why do posts in WordPress need to be assigned to a specific category? Can they not just float independently?

I’m sure there’s a reason behind this (if you know it or can offer some insight into possible reasons, please share)… just thought I’d pose the thought and see what you all think.

Ryan, the editor at WPCandy, broadcasts a video podcast called “The Sweet Plugin of the Day”, where he reviews a plugin that he finds useful and/or interesting. Matty Theme QuickSwitch, a plugin I recently released to make quick switching between WordPress themes easier, was recently featured on “The Sweet Plugin”.

Thanks for the great review and kind words, Ryan.

Click to read the full text-based review of Matty Theme QuickSwitch.

With my mission at hand, I set to work. I’d been thinking about this for a while after writing the initial blog post and am please to say that I have found a solution. Please be sure you’ve read through the initial blog post, as the main points are covered over there.

There are a few steps we need to go through here. They’re pretty straight forward, so bear with me.

Reference the global $post object

First things first. How do we know what page, post or custom post type entry we’re working with? We need to get this information from WordPress. Luckily for us, WordPress also needs to know which entry we’re editing. We get this information by adding the following to the beginning of our function:

global $post;

This lets us work with the variable $post, which was previously created outside of our function. This variable is an object that holds information about the entry we are currently editing (ID, title, content, template, etc). We will be using this information at a later stage to insert our custom CSS file(s).

Due to this being a custom solution specific to a particular page, post or custom post type entry, this solution will only truly take effect on the “Edit” screens when targeting a specific entry or an entry with a particular custom template applied.

Check if the file we’re looking for exists

We wouldn’t want to call a file that we know doesn’t exist. Therefore, we will use a conditional (in this case, an IF statement) to determine whether or not to look for our custom CSS file, based on whether or not it exists.

If the CSS file exists, add it to the list of CSS files to include

After the line where we include our main editor-style.css file, add the following code:

if ( file_exists( trailingslashit( get_stylesheet_directory() ) . 'assets/css/editor-style-' . $post->post_type . '.css' ) ) {

	if ( !empty($url) )
 	$url .= ',';

	// Change the path here if using sub-directory
 	$url .= trailingslashit( get_stylesheet_directory_uri() ) . 'assets/css/editor-style-' . $post->post_type . '.css';

} // End IF Statement

The above code checks if our custom CSS file (in this case, for a post type-specific CSS file) exists and, if it does, adds it to the list of CSS files to include in the tinyMCE editor. We include it after checking for our main editor-style.css file so that any of our custom CSS declarations override the defaults we have in the main editor-style.css file.

Extending this functionality

In the above example, I am including a custom CSS file based on the post type of the entry being edited. Altering this is relatively straight forward and can allow for custom CSS files depending on date published, post publish status, custom template being used and virtually any condition imaginable.

As an example of extending this functionality, we will include a file based on post ID. To do this, simply paste the above code into the function again and replace all instances of `post_type` with `ID` (such that $post->post_type becomes $post->ID). Thus, if a post has an ID of 7 (for example), the system will look for a file called editor-style-7.css and, if it exists, include it in the tinyMCE editor.

Please note that using post IDs can result in a large quantity of custom CSS files and is not recommended. The above is simply an example for extending the functionality we just created.

Folks, there you have it. Not too difficult, I hope. This allows for further customisation of the WordPress tinyMCE editor, creating a richer user experience for the bloggers using your theme, as well as creating a more accurate representation of what the post will look like on the front end of their WordPress website.

What are we going to achieve today?

Today, we’re going to style the editor in the WordPress backend to resemble the content as it is in the theme that is being used on the frontend. Simple objective, so lets get started.

What do we need?

We’ll need three things to get this done: an editor-specific CSS stylesheet (I usually call this editor-style.css), a PHP function to do the work and a WordPress filter to piece things all together.

Creating the editor-specific CSS stylesheet

To do this, we need to keep in mind one thing: we’re cloning the styling of our theme’s content area into a new stylesheet. Simply loading the existing stylesheet in place of this file will not work out properly. One other thing to note is, the content area styles are now to be placed within the .mceContentBody{} CSS style. In addition to copying and pasting the content styling from my theme  (and changing all instances of #content to read .mceContentBody), I have also imported the CSS reset script I use via an @import call. This is to ensure added consistency within the editor styling. If your theme uses a CSS reset file, I would recommend importing it as well.

A snippet from my editor-style.css file looks like this:

.mceContentBody { color: #666666; font-family: Arial, Helvetica, sans-serif !important; font-size: 12px; line-height: 18px; width: 640px; }
		.mceContentBody a, .mceContentBody a:visited { background: none; color: rgb(60, 130, 170); text-decoration: underline; }
		.mceContentBody a:hover { background: none; color: rgb(60, 140, 180); text-decoration: underline; }

Writing the PHP function to do the work

Right, folks. This is where we do the main work involved with this. We’ll be writing a function to add our new editor-style.css file into the mix with the existing tinyMCE stylesheet in the backend. The function looks like this:

/**
 * matty_editor_style()
 */

function matty_editor_style( $url ) {

  if ( !empty($url) )
    $url .= ',';

  // Change the path here if using sub-directory
  $url .= trailingslashit( get_stylesheet_directory_uri() ) . 'assets/css/editor-style.css';

  return $url;

} // End matty_editor_style()

And in English, this function reads like this:

The function accepts $url as a parameter. This is the existing tinyMCE stylesheet, passed through the WordPress filter. More on that in a bit. If the URL is provided (and not empty), add a comma (,) at the end of it. After that, create the URL to our editor-style.css file, as it sits in our theme folder, and add it to the end of $url. Return out the newly filtered $url back to the system.

The WordPress filter that makes it all happen

The last line. Nice and simple.

add_filter( 'mce_css', 'matty_editor_style' );

This is using the native WordPress function, add_filter(), to take in the ‘mce_css’ stylesheet (the apply_filters() function is applied to the main tinyMCE CSS stylesheet before it is loaded into the system) and add the editor-style.css file into the mix with the existing file. No mess, no fuss.

Place the above PHP function and filter in your theme’s functions.php file, and you’re set.

And there we have it, folks. The editor in the WordPress backend no resembles the frontend of our WordPress theme. I hope this tutorial helps you in creating beautiful and easy to use content managed websites with WordPress.

“Callback”, you say? Erm… what’s that?

“callback” is one of the arguments we can pass to the wp_list_comments() function. The “callback” argument expects a string which, in this case, is the name of our callback function. Essentially, by using the “callback” argument, we’re saying to WordPress; “okay, that layout looks cool, but use this awesome layout instead”.

So… this function…

Right. The meat of this method is the callback function itself. This is the code that will be used to display each comment in the list. No need to create the list itself, just the items (as is most likely done in your comments.php theme file at this time). The callback function we’ll be creating looks something like this:

<?php
/**
* matty_comment_layout()
* A callback function to be used with the wp_list_comments() function.
*/
function matty_comment_layout ( $comment, $args, $depth ) {
$GLOBALS['comment'] = $comment;
$path_to_default_gravatar = get_bloginfo('stylesheet_directory') . '/assets/images/gravatar.png';
$twitter = '';
$twitter = get_comment_meta( get_comment_ID(), 'twitter', true );
if ( $twitter != '' ) {
$twitter = strtolower($twitter);
$twitter = str_replace(' ', '', $twitter);
$twitter = str_replace('.', '', $twitter);
$twitter = ' <span>(<a href="http://twitter.com/' . $twitter . '" rel="nofollow">' . $twitter . '</a>)</span>';
} // End IF Statement
// Sanitise gravatar and make sure the image has an ALT attribute that isn't empty.
$gravatar = get_avatar($comment,$size='48',$default=$path_to_default_gravatar );
$gravatar = str_replace ("alt=''", 'alt="' . $comment->comment_author . '\'s Gravatar"', $gravatar);
?>
<li <?php comment_class(); ?> id="comment-<?php echo $comment->comment_ID; ?>">
<div><?php echo $gravatar; ?><?php printf( __('<cite>%s</cite>'), get_comment_author_link(), $twitter ); ?></div>
<div><?php printf(__('Posted %1$s at %2$s (%3$s ago)', 'matty'),
get_comment_date(),
get_comment_time(),
human_time_diff(get_comment_date('U'), current_time('timestamp')) ); ?></div>
<?php if ($comment->comment_approved == '0') _e("\t\t\t\t\t<span class='unapproved'>Your comment is awaiting moderation.</span>\n", 'matty') ?>
<div><?php comment_text(); ?></div><!--/.comment-content-->
<div><?php printf(__('<a href="%1$s" rel="bookmark" title="Permalink to ' . $comment->comment_author . '\'s comment">Permalink</a>', 'matty'),
'#comment-' . $comment->comment_ID );
edit_comment_link(__('Edit', 'matty'), '<span>', '</span>'); echo get_comment_reply_link(array_merge( $args, array('depth' => $depth, 'max_depth' => $args['max_depth']))) ?></div><!--/.comment-links-->
<?php
} // End matty_comment_layout()
?>

Okay, that’s a long snippet. Lets go through it.

function matty_comment_layout ( $comment, $args, $depth ) {

This is our opening function tag. What’s important to note here is the passing of three arguments: the $comment we’ll be displaying, the $args that go along with that comment and the $depth of the comment in the structure.

$GLOBALS['comment'] = $comment;
$path_to_default_gravatar = get_bloginfo('stylesheet_directory') . '/assets/images/gravatar.png';
$twitter = '';
$twitter = get_comment_meta( get_comment_ID(), 'twitter', true );

if ( $twitter != '' ) {

$twitter = strtolower($twitter);
$twitter = str_replace(' ', '', $twitter);
$twitter = str_replace('.', '', $twitter);
$twitter = ' <span>(<a href="http://twitter.com/' . $twitter . '" rel="nofollow">' . $twitter . '</a>)</span>';

} // End IF Statement

// Sanitise gravatar and make sure the image has an ALT attribute that isn't empty.
$gravatar = get_avatar($comment,$size='48',$default=$path_to_default_gravatar );
$gravatar = str_replace ("alt=''", 'alt="' . $comment->comment_author . '\'s Gravatar"', $gravatar);

I’ve bundled the above together as it’s all extra information that isn’t directly part of the comment itself.

The first line is to ensure we have the correct data for our comment. Below that, $path_to_default_gravatar is where we set the URL of a custom gravatar that we would like to use to replace the default gravatar used. This can be really useful when doing advanced premium WordPress themes. Now, onto the Twitter username.

We create a variable called $twitter, to which we will assign whatever is returned from the native WordPress function, get_comment_meta(). This function takes in the ID of the comment we’re currently processing, the field name (in this case “twitter”) and whether to expect a single value, instead of an array of values (in most cases, this should just be set to true, as we’re only expecting a single value here). If $twitter isn’t empty, we remove and spaces or full-stops from it and create an anchor XHTML tag pointing to the user’s Twitter profile page.

The last two lines get the user’s gravatar and make sure it has alternative text, to keep things neat and tidy. We’ve also told the get_avatar() function that, should it not find a gravatar for the user, it must use $path_to_default_gravatar as the default gravatar to display.

The rest of the comment function looks like this:

<li <?php comment_class(); ?> id="comment-<?php echo $comment->comment_ID; ?>">
<div><?php echo $gravatar; ?><?php printf( __('<cite>%s</cite>'), get_comment_author_link(), $twitter ); ?></div>
<div><?php printf(__('Posted %1$s at %2$s (%3$s ago)', 'matty'),
get_comment_date(),
get_comment_time(),
human_time_diff(get_comment_date('U'), current_time('timestamp')) ); ?></div>
<?php if ($comment->comment_approved == '0') _e("\t\t\t\t\t<span class='unapproved'>Your comment is awaiting moderation.</span>\n", 'matty') ?>
<div><?php comment_text(); ?></div><!--/.comment-content-->
<div><?php printf(__('<a href="%1$s" rel="bookmark" title="Permalink to ' . $comment->comment_author . '\'s comment">Permalink</a>', 'matty'),
'#comment-' . $comment->comment_ID );
edit_comment_link(__('Edit', 'matty'), '<span>', '</span>'); echo get_comment_reply_link(array_merge( $args, array('depth' => $depth, 'max_depth' => $args['max_depth']))) ?></div><!--/.comment-links-->

The one very important thing to note here is the lack of a closing </li> tag. WordPress inserts this automatically for us. While this still puzzles me, I’m sure there’s a decently good reason for it.

This code looks a bit random, doesn’t it? Well, it’s not really all that bad. Lets take a look.

We open the <li> tag and call the comment_class() WordPress function. This adds necessary microformats and comment-specific classes to the <li> for this comment. We also give it a unique ID.

Next up, we create a containing <div> tag and echo out our $gravatar image, as well as a prepared statement containing the comment author’s name and a link to their website (via the get_comment_author_link() function) and our $twitter URL, created in the snippet above.

Below the comment author information, we echo out a prepared statement with three values: the comment date, comment time and a human-readable version of how long ago the comment was posted (for example, 3 days ago).
If the comment has not yet been approved, we let the user know this with <?php if ($comment->comment_approved == '0') _e("\t\t\t\t\t<span class='unapproved'>Your comment is awaiting moderation.</span>\n", 'matty') ?>.

Now for the main event. The comment itself. A simple function called comment_text() gets this part of the show done.

Next up we create links that apply to this comment. In the above snippet, we create a permalink to the comment, an edit link for users who are logged in and have access to edit comments and a reply link (if we’re not too deep into the comments thread) that users can use to reply to the comment.

That’s all, folks!

Yep, that’s it. In the above snippet (which is almost a store-and-use-without-thinking snippet, in my opinion), we’ve created a customised layout for the way each comment is displayed, integrated a custom default gravatar, displayed a human-readable version of how long ago the comment was posted and integrated a Twitter username, submitted by the user when the comment was first made.

I’d really appreciate your thoughts on and ideas for this in the comments below.

Pretty cool, hey?