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

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.

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.

Over the last few weeks, WordPress plugin development has become one of my favourite things to do. I find it exciting to be able to create functionality, incorporate it seemlessly into the WordPress system and see it work smoothly with the other modules. While plugin development for WordPress is incredibly powerful, it also carries with it a few areas where people commonly stumble over and potentially lose interest in their code… which could be the next big thing. Here are a few guidelines I’ve picked up in order to step over the stumbling blocks.

1. Understand actions, filters and hooks, where to use which action and their limitations.

Actions, filters and hooks are what allow developers to insert their code into virtually any part of the WordPress system. While there are only almost 400 hooks documented, there are in fact around 800 hooks in the WordPress system. The WordPress codex has a great reference for actions, filters, hooks and how to use them.

2. register_activation_hook() does not function the same way as add_action().

While looking through the WordPress forums, the register_activation_hook() function (runs the function you pass to it when the plugin is activated) has come up as a regular topic of conversation. Users are attempting to display text on activation, using it as if it were the add_action() function. register_activation_hook() does not function the same way. The function, the way I understand it, works in an almost overall scope, not having access to variables within your plugin for display purposes. In short, don’t try to echo or print variables with this function. It won’t work. The function is best used for doing common setup such as installing database tables, setting default options, etc.

3. Use dbDelta instead of mysql_query or $wpdb->query() when installing database tables.

The dbDelta function (which you pass your database query to) is used when installing tables into your WordPress database. It is also used as an upgrade script in the same area. Don’t forget to include the WordPress upgrade script before running dbDelta(). The include looks like this:

require_once(ABSPATH . 'wp-admin/includes/upgrade.php');

4. Understand the scope of your plugin and work within it.

As mentioned above, WordPress plugins can be used to hook into essentially any area of the WordPress system. This includes standalone menus, as well as running actions when a post or page is saved, for example. Understanding the objective/s and scope of one’s WordPress plugin is essential to choosing the correct approach for the plugin. If it’s a short plugin with specific objective, there’s no need, in my opinion, for more than one or two files. Keep it simple. On the other hand, if the plugin is a large, standalone module, I don’t believe there’s any reason to have cluttered files of hundreds of lines of code, where an Object Oriented approach would ultimately serve as a much cleaner and more extendable solution.

5. Plan, plan, plan.

Planning on paper, drafting a code map on screen, talking it through with other developers. Planning a plugin can never be done too much. It helps with all of the above steps as well as helping to see where you need to be at the end of the development and planning a solid roadmap for the journey to get there. Also, other users may have ideas that could streamline your plugin even further.

These are just a few things I’ve picked up on my WordPress plugin development journey. I’ll post more if and when they come up. I hope these tips are useful and help in overcoming the potential stumbling blocks when getting started with WordPress plugin development.