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.

While we all have our own preferences, it’s important to solidify a few areas when approaching code and to, ultimately, hone the developer’s mindset into certain guidelines. Below are a few thoughts I have running through my mind constantly while developing:

1. Minimize lookups.

This one is crucial when developing systems with heavy load. How many times are you hitting the database for information and how can you minimize that number? For example, when using the Transients API in WordPress, why would you run get_transient() again after you’ve just set the transient up? You’ve already got the data, so there’s no need.

2. D.R.Y (don’t repeat yourself).

This is a common development practice. Don’t repeat yourself. If you’ve got, for example, two functions that perform API requests, create a function that runs the API request with a few parameters to customise it in each case, rather than coding the request twice.

3. One function, one purpose.

This one helps me every day. It also ensures that your code is kept clean. If, for example, you have to display a collection of posts with specific criteria, why compile one function to do it all, when you could have a small function to get the data from the database and a second small function to output the data neatly? Surely that would make your code easier to read and maintain? Yep, it would.

4. Do I need this function here?

This one is about load and separation of code. Why load extra functions when you don’t need them in a specific context? Keeping this in mind ensures that you keep your code in “bite size chunks”, for example, splitting admin-related functions versus frontend functionality.

These items, while simple to adhere to, can alter the way a developer approaches a project, as well as creating a better end result. Most are also common development practices that most developers should be familiar with, making it easier for other developers to read and understand your projects.

Do you have any tips and tricks that help you day to day while developing?

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

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.

For me, a blog redesign means quite a lot. It means the opportunity to hone my skills, experiment with new ideas and techniques and put a fresh coat of paint and a new engine behind my blog. Let me elaborate on the paint and engine for a moment.

Over the past few months, I’ve designed and developed at least 3 new themes for this blog. By the time I reach what looks like the end of the theme, I’ve become bored with the design or feel the code is now “old” and would prefer to start again on a new design idea I’ve come across while scouting around online for inspiration. This has proven to be a vicious cycle whereby the ultimate goal is never achieved: a new blog design.

Why not just get someone else to do it?

It comes down to personal preference on this one. I’m a professional web developer and am trained and qualified as a designer, so why not design and develop the theme myself? In addition, am I not letting an opportunity to show my abilities get put aside? In addition, at the end of the day, I can say that I designed and developed the entire theme from the ground up, which makes the achievement that much sweeter.

The search for perfection?

Designers often run into this, from what I’ve seen. There’s always something that can be done to improve a design further. Pixels can be shifted around until blue in the face… but will it ever be finished? The same goes for development. That one line of code can be optimised, written and re-written over and over until it becomes almost meaningless. Does it really improve or contribute anything?

Yes, it does. Does it have to be done right this very second, though? If it’s not a life-changing development decision, or an integral part of the design, probably not. Having the code as optimised as possible is great… but if no-one sees it, what good is it doing?

Final words…

With that said, I’ve come to a new conclusion (and am writing it in this post for posterity): a blog’s design is never truly “finished”. With the web evolving at the rate it is, it makes perfect sense to revamp your web presence every few months… kind of like putting a fresh coat of paint on a house. Therefore, I’ve published this redesign as is and will continue to work on it and make improvements. That way, the design and development will remain constantly fresh, and I’ll be able to hone my skills and experiment on things on a more regular basis, rather than tying that down into a phase of “I am now redesigning my blog, therefore, let me experiment”.

If you spot anything that could do with some more cowbell, give me a shout and I’ll get right on it.

As a developer, the problem and solution are usually quite clean-cut (such is the nature of code, prodominantly). The solution, however clean-cut it may be, isn’t always visible when approaching a coding task. At times like those, I employ a theory:

Whatever you do to figure out the solution, whatever pencil-tapping or repeated contact between your head and desk occurs, the end result will work and be exactly as per the task set out to you.

Knowing this, the task of achieving the goal becomes seemingly less stressful and a bit clearer to tackle. In addition, I find it important to clear one’s head, move away from the problem for a few minutes and give it some thought from a different angle.

That’s my theory, anyways.

Stop. Think. Re-evaluate.

The process

So, what exactly are we doing here? To put things in point form, this is the process:

1. Create custom rewrite rules
2. Add our new variables to the public_query_vars array
3. Flush (and thus, regenerate) all WordPress rewrite rules
4. Add our functions from steps 1, 2 and 3 into WordPress via actions and filters

Right, so lets get down to it then.

Create custom rewrite rules

Rewrite rules use a  token which is replaced by the necessary query variable. For example, we create a token called %token% which, using a regular expression, gets replaced by “id=”. This will be shown further below.

Add our new variables to the public_query_vars array

By default, WordPress has an array of public query variables which can be used within templates and plugins. In order to access our query variables (ie: the “id=” in the above example), the variable needs to be added to the public query vars array.

/**
* add_custom_page_variables()
* Add the custom token as an allowed query variable.
* return array $public_query_vars.
**/

function add_custom_page_variables( $public_query_vars ) {
$public_query_vars[] = 'car';

return $public_query_vars;

} // End add_custom_page_variables()


Flush all WordPress rewrite rules

By flushing the rules, we are forcing WordPress to regenerate it’s rules list, including our new rules in the rules set.

/**
* flush_rewrite_rules()
* Flush the rewrite rules, which forces the regeneration with new rules.
* return void.
**/

function flush_rewrite_rules() {

global $wp_rewrite;

$wp_rewrite->flush_rules();

} // End flush_rewrite_rules()


Add our functions from steps 1, 2 and 3 into WordPress via actions and filters

Now that our functions have been created, we need to hook them into the various necessary processes within WordPress. We do this using a combination of actions and filters.

Our first action runs on initialization. This is where we flush the rewrite rules in WordPress, causing them to be regenerated.

The regeneration brings us to action number 2. This is where we create our custom rewrite rule, hook it on to the global rewrites array and generate the rules.

Our final line is our filter where we add the new public query variable into the global public_query_vars array. We then later use this array to access the variable in our theme.

add_action( 'init', 'flush_rewrite_rules' );
add_action( 'generate_rewrite_rules', 'create_custom_rewrite_rules' );
add_filter( 'query_vars', 'add_custom_page_variables' );


The scope of rewrite rules

By default, WordPress rules are applied across all pages. Thus, the tag “%pagename%” is used in place of a specific page slug. To use your rules on only a single page, replace “%pagename%” with a specific page slug. You can either generate this slug dynamically or staticly.

That’s all, folks

And there you have it. A custom rewrite rule in WordPress. This post is intended as a starting point for using custom rewrite rules in WordPress. There are virtually infinite possibilities created when using rewrite rules (either one or many) and some really interesting plugins and functionalities can come out of using rewrite rules.

Thanks must also go to Joe Hoyle who’s use of rewrite rules provided the inspiration for this tutorial.

If there’s anything that isn’t clear, please comment below and I’ll do my best to clarify and help.

Before I go… wouldn’t you like the files?

I thought you might. Click below to download the code written above (it’s been written into a class for easy implementation in your projects).

Download the  ”Custom URL rewrites in WordPress – A Getting Started Guide” code example.