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?

As many of you know, I like to keep my computer as clean as possible. If I don’t use an application, it gets removed and everything that could go onto the machine is thought through before it’s loaded on. Thus, I don’t have PowerPoint, Keynote or anything of the sort… because I don’t need it. Suddenly, I did. Enter SlideRocket.

SlideRocket is a web-based presentation creation tool, similar to PowerPoint or Keynote. They also have a web-app in the Google Chrome Web Store, which is how I got started on it.

The team at SlideRocket have, by the looks of things, put much time, effort and thought into their product and how it interacts with it’s users. While the interface is familiar to anyone who has ever used PowerPoint or Keynote, it doesn’t get in the way of you creating your presentation. At no point did the interface bug me, crash or do anything I wasn’t expecting it to do. This is a welcome change in the arena of presentation tools.

My only concern was the lack of a free export of my presentation (maybe I didn’t see it?). While SlideRocket offers many export options, from PowerPoint to PDF, standalone OS X to standalone Windows, it seems I was unable to export my presentation for free (the above mentioned exports are available after a paid upgrade). While I understand the need for paid upgrades in a free application, I feel it would be advantageous to have some form of basic free export (even just to a set of static HTML files would be good… for simple, in-browser presenting).

To sum up, I really enjoyed my experience with SlideRocket… so much so, in fact, that I decided to blog about it. I needed a presentation quickly and was able to create one in a few minutes, with no hassle. Not only that, but with SlideRocket being a web-app, I could easily add Jeff into the mix and collaborate with him on the slides over the web-app (I mean, we sit next to each other at HQ, but still… collaboration of this nature is invaluable in a presentation tool).

The next time I do a presentation, I’ll most likely jump back into SlideRocket without thinking twice. Thanks for the awesome web-app, guys!

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.

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.

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.

If you’ve ever coded for a system that is build in a convention you’re not used to (for example, coding using a MVC framework, if you’re not used to it), this concept will begin to make sense. It refers to the almost complete paradigm shift required when approaching an unfamiliar coding framework or system. Here are a few things that I’ve found ease the process of coding with the other side of your brain.

1. Find people who code using the other side of their brain, more often.

Knowing one or two people who are used to the particular environment in which you are coding can be invaluable. It’s most useful, I believe, with those smaller tweaks and refinements that you may need to make… or the small and unexpected bugs in your code.

2. If the system has a user guide, keep it open.

User guides can often be bloated and unusable. If the documentation has a function reference and a brief explanation of the concepts behind the system, you’ve got it.

3. Pay attention to coding conventions.

If the original designers of the system are coding in a particular convention, stick to it. There’s usually a reason for the convention and sticking to it will save you time and potential future re-coding anyways.

4. Try to lay as much groundwork as possible before integrating the system with your code.

Pay attention to the finer details of the system and try to view the system on a more abstract level. This will enable you to see the bigger picture and to code or style any areas you may need to back-track and do at a later stage.

I hope these short tips are useful. If you have any to add, please add them in the comments.

1. Maintenance Mode

This plugin is truly awesome. It allows the developer and end-user to test the WordPress installation thoroughly, on the server where it will eventually be hosted, without displaying it to the world. It also allows the user to, as it says in the title, take the website down for maintenance at any stage and leave a message for users letting them know of the downtime.

2. All-in-One SEO Pack

I know this isn’t the be-all and end-all of SEO. It does have some nice features though. SEO-friendly re-writing of page titles (if this isn’t already in your theme, or you don’t have access to change it), canonical URLs and page-specific descriptions and keywords. All in all, a straight-forward and very useful plugin.

3.  Google Sitemap Generator

Assists with dynamic generation of an XML sitemap, to be submitted to Google. This plugin also allows for various sitemap formats (XML, zipped, etc) and customisation of priority settings for various areas of your WordPress installation.

4. Askimet

It comes standard with your installation and has proven very useful in blocking spam comments. Does what it says on the box, really.

5. Your Own

Writing your own functionality is, I believe, very important. It has helped me work my way around the WordPress system, how it all hooks together, how to use functionality correctly and how to further enhance WordPress websites. It doesn’t have to be shiny and new… as long as it serves a purpose and helps.

A short and sweet list of a few plugins that I like to keep in the box. What’re yours?

* These plugins are in no particular order.

http://websiteurl.com/parentpageslug/subpageslug (Note: note a real URL)

What if you require a value to be set depending on the highest level parent page? The process looks like this:

1. Get the permalink for the current page (using the global $post object).
2. Remove the website URL from the string, leaving only the full slug.
3. Split the slug into an array, using the ‘/’ as a separator.
4. The route slug should be at one of the indexes in your array (most likely index 1).

To get the information for the root page, we are going to use a native WordPress function called “get_page_by_path“. To run this function, we will declare it like this:

$root_page = get_page_by_path($root_slug);

This line returns an object (into $root_page) containing the information for the root page of the page we are currently viewing.

I’ve left points 1 to 4 up to you to work out. Everyone has their own way of coding things. If you know of a smoother or quicker way to achieve the same result, please let me know.

Thanks guys. I hope you found this quick snippet to be useful.