Our mission is to teach Web Design, Development and iOS to people everywhere, in order to help them achieve their dreams and change the world.

I have been a member of Treehouse since the end of February and I love it! What’s so fantastic about it is you get to unlock badges as you go along watching videos that teach you things like:

• HTML – Lists, Objects, Text, Forms, HTML5
• CSS – Selectors, Box Model, Page layout, CSS3 Techniques
• Typography, Web Fonts, Photoshop
• JavaScript, Ruby, iOS
• …and so much more!

The unlocking of badges is really gamification on the web. Each Badge has a number of videos that you can watch, and then a quiz to complete. Once you have passed the quiz, you’ve unlocked the badge and it goes on your public profile that you can show off. There are also “Code Challenges” where you have to follow instructions to write HTML, CSS, etc. right in the browser, and unlocks a special badge for that challenge.

Treehouse also just started a referral program – if you click the banner below and join, you get 50% OFF your first month!

If you want a preview, you can check out Treehouse on YouTube. Some videos they have aren’t just for learning, but reward videos that you get to watch after completing certain badges. One of my favourites is Meet Mike the Frog.

What’s also great about Treehouse is you can suspend your account at any time and not get billed until you re-activate it. They also have a Student membership if you email them a photo of your student ID.

I highly recommend Treehouse to anyone, from beginners to advanced. Even if you know the basics (or more) it’s still fun to unlock the badges (gamification at work!).

This tutorial is going to show you how to add your own Custom Meta Box to your posts, pages, or your own custom post types. Custom meta boxes allow you to save additional information. Continuing on from the previous tutorial, I am going to add a custom meta box to my custom posts type “Cats”, which I will use to save the cat’s age and favourite toy.

For simplicity, we will create our custom meta box in our functions.php file. You can edit this file by going to Appearance > Editor in your WordPress admin panel, or using a text editor with FTP.

To begin, we first have to create the custom meta box. We do this by using a function we have used already, add_action().

// Create custom meta box
add_action( 'add_meta_boxes', 'cf_cats_meta_box', 1 );

The first parameter is the name of the action that the second parameter is hooked to. add_meta_boxes runs when the page to edit your post/page loads. The second parameter is the name of our function that prints out the meta box itself. Feel free to name this in a way that makes sense for your custom meta box. I am continuing to use “cf” as my prefix from the previous tutorial, and since this is my “Cats” custom post type, I put that in there as well. The last parameter is set to 1 for priority over other functions, which is optional.

Next we need to create our function that we are calling from add_action().

// Display custom meta box
function cf_cats_meta_box() {
	add_meta_box( 'cf-cat-meta-box', 'Cat Details', 'cf_cat_details', 'cf_cats', 'normal', 'high' );
}

We got a bit going on here, so let’s break it down. add_meta_box() is the function that displays our custom meta box. Inside we have some parameters. The first is the HTML ID name of our meta box. The second is the title of the meta box, which the user will see. The third is the name of our function that we will create to display the content that is INSIDE of our meta box, such as a form. The fourth parameter is the post type. This can be set to ‘post’, ‘page’, or your own custom post type slug. In the previous tutorial I created the post type ‘cf_cats’, which is what I am using here. The last two parameters are for where the meta box should be placed on the edit screen (both optional).

At this point, this is what our custom meta box looks like:

Great! But not very exciting, eh? Now we need to actually have something inside of our meta box.

// Function to display what is inside of our meta box
function cf_cat_details( $post ) {

	// Retrieve saved metadata if it exists
	$cf_cat_age = get_post_meta( $post->ID, '_cf_cat_age', true );
	$cf_cat_toy = get_post_meta( $post->ID, '_cf_cat_toy', true );

	// Create a nonce field for verification
    wp_nonce_field( 'cf_submit_cat', 'cf_cat_check' );

    // The form inside our meta box
	echo '<table class="form-table">
			<tr valign="top">
				<th scope="row"><label for="cf_cat_age">Age:</label></th>
				<td><input type="text" name="cf_cat_age" size="30" maxlength="2" value="' . esc_attr( $cf_cat_age ) . '" /></td>
			</tr>
			<tr valign="top">
				<th scope="row"><label for="cf_cat_toy">Favourite Toy:</label></th>
				<td><input type="text" name="cf_cat_toy" size="30" maxlength="100" value="' . esc_attr( $cf_cat_toy ) . '" /></td>
			</tr>
		</table>';
}

In lines 5 and 6 we are retrieving any previously saved metadata, if it exists, and storing it in variables. In line 9 we have our nonce check, which is for security (more on that later).

Now for the content that we see inside of our meta box, I have decided to create a simple form where a user can input their cat’s age and favourite toy. For the values, you can see we have our variables we declared earlier. This allows us to see what the previous stored data is, if any. It is also important to escape any user inputted data in forms, so we use the esc_attr() function.

If you have a large form, it may be easier to have it in a seperate file and include it in (which is typically done for plugins). However, for this tutorial we will keep it in the same file as it is a small form.

And that’s it! Well, not quite. We now have a custom meta box, but if we try to fill out the form and save the post, the fields return empty. The title and description save, but not our meta box data. That’s because we need to tell WordPress to save the metadata.

// Update/Save cat metadata
add_action('save_post', 'save_cat_metadata');

function save_cat_metadata( $post_id ) {

	// Verify if this is an auto save routine.
	if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
		return;
	}

	//Check permissions
	if ( !current_user_can( 'publish_posts' ) ) { // Check for capabilities, not role
		wp_die( 'Insufficient Privileges: Sorry, you do not have the capabilities access to this page. Please go back.' );
	}

	// Check nonce named cf_cat_check
	// Verify this came from the our screen and with proper authorization
	if ( !isset( $_POST['cf_cat_check'] )  || !wp_verify_nonce(  $_POST['cf_cat_check'], 'cf_submit_cat' ) ) {
		return;
	}

	// OK, we're authenticated: we need to save the data
	// Verify the meta data is set
	if ( isset( $_POST['cf_cat_age'] ) && isset( $_POST['cf_cat_toy'] ) ) {
		// Save meta data
		update_post_meta( $post_id, '_cf_cat_age', strip_tags( $_POST['cf_cat_age'] ) );
		update_post_meta( $post_id, '_cf_cat_toy', strip_tags( $_POST['cf_cat_toy'] ) );
	}
}

Again, we use the handy add_action() function to hook our own function (parameter two) to the save_post action (parameter one), which as you can guess, happens on saving posts.

Now in our own function, we first check if it is an autosave routine. If it is, we don’t want to do anything as our form hasn’t been submitted. Then we check for permissions. You should always check for permissions based on user capability not role, as capabilities for certain roles (ie. author) can be changed. Following that, we check if our nonce exists.

Once we’ve got the okay, then we save (or update) the meta data. We have three parameters in the update_post_meta() function. The first is the ID of the post, stored in the variable $post_id. The second is the name of the meta key (in the database) of the custom field. And the third is the meta value of the field that we are storing in the database (key/value pairs!).

We use the update_post_meta() function because it acts like the add_post_meta() function if the meta key (in the database) does not exist (creates it in the database). Otherwise, it just updates the value if the key does exist. Best of both worlds!

And we’re done! Here’s what my meta box looks like:

Any questions or comments, please reply below!

Ps. I have used some security in this tutorial, but it is too big of a topic that it really needs it’s own. Better yet, the Codex is a great place to start. Make sure to always use security checks, and to sanitize and validate any and all data, especially user input! For example, after the nonce check you could check that data has been input if it is required (you can also use the HTML5 “required” attribute in your forms), and also use preg matches etc., for specific types of data such as emails or phone numbers (which can also be done within forms using HTML5. But you should always have a PHP backup!).

I have been working with Custom Post Types recently, so I want to start off the series with them. Custom Post Types are just like Pages and Posts, but you can call them whatever you like. They can be used for a variety of content such as Events, Bands, a Book database, Cars, Recipes… if you can think of it, it can probably be a Custom Post Type! They are handy because you can separate them from your regular blog Posts, they can be integrated into your themes and plugins, and even created just by using functions.php.

For simplicity, we will create our Custom Post Type in our functions.php file. You can edit this file by going to Appearance > Editor in your WordPress admin panel, or using a text editor with FTP. I’m going to be creating a post type called Cats.

My cat Azaezel.

We’ll begin by setting up our Custom Post Type using the add_action() function. We use this function to hook our function (second parameter) to an action (first parameter). The add_action() function can take two more parameters, but we only need these two for now (find out more at the WordPress Codex).

// Set up the custom post type
add_action ( 'init', 'cf_cats_post_type' );

The first parameter, ‘init’, means after WordPress has loaded. The second parameter simply calls our function cf_cats_post_type(). We are telling WordPress to call our function after it (WordPress) has fully loaded.

You can change the name of your function to whatever you like based on what your Custom Post Type is. It’s a good idea to use some sort of prefix, especially if creating a plugin, to avoid conflicts with other function names. So for this tutorial I will use cf_, which is simply the first letters of my first and last names followed by an underscore.

Next, we will set up the arguments for our post type in our function.

function cf_cats_post_type() {
	$cats_labels = array(
		'name' => 'Cats',
		'singular_name' => 'Cat',
		'add_new' => 'Add New Cat',
		'add_new_item' => 'Add New Cat',
		'edit_item' => 'Edit Cat',
		'new_item' => 'New Cat',
		'view_item' => 'View Cat',
		'search_items' => 'Search Cats',
		'not_found' =>  'No Cats Found',
		'not_found_in_trash' => 'No Cats Found in Trash',
	);
	$cats_args = array(
		'labels' => $cats_labels,
		'public' => true,
		'query_var' => 'cf_cats',
		'hierarchical' => false,
		'menu_position' => 5,
		'show_in_nav_menus' => true,
		'rewrite' => true,
		'supports' => array( 'title', 'editor', 'thumbnail' ),
	);

	// Register the custom post type
	register_post_type( 'cf_cats', $cats_args );
}

The first part starting on line 2 is our labels, which are pretty self-explanatory. The labels (which is an argument in line 15) is an array of text strings shown throughout the admin backend for that post type. You don’t have to set every one if you don’t want to as WordPress provides defaults, but I feel it is a good idea to do so for consistency.

Starting on line 14, we have our array of arguments. They may not be obvious as to what they do at first glance, and again you can choose what you want to set or not. I haven’t included all of them here either. Because the WordPress Codex has a thorough explanation of all labels and arguments, you can find all you need to know about them there.

Finally, in the last bit of our function at line 26, we will register our post type. This is done by calling the register_post_type() function. The first parameter is the name of our post type. The second is the array of arguments that we set earlier, stored in the variable $cats_args.

Here’s a preview of my post type. As you can see, mine is below ‘Posts’ in the admin menu (‘menu_position’ => 5) and I have created a post for my cat. You can see how our labels worked, with “Cats” and “Add New Cat” showing up in the admin backend.

And we’re done! If you have any questions or comments please feel free to leave a response below.

I’m not going to explain the entire video as it really needs to be watched, but here’s a quick summary from YouTube: “KONY 2012 is a film and campaign by Invisible Children that aims to make Joseph Kony famous, not to celebrate him, but to raise support for his arrest and set a precedent for international justice”.

The film has a very powerful message, and is smartly directed at the younger generations. Personally, I believe that if we can all contribute in some way, big or small, we can make a difference. We can change history. Twenty-six years is far, far too long for something such as this to be going on. And, my hope is that this will inspire us to work towards solving other world issues too.

I have embed the video below. If there is issues, you can view it directly on Youtube.

I initially came across the whole thing from Chris Coyier at Css-Tricks.com, followed by tweets from various web professionals on Twitter. Essentially, Mozilla (those behind the Firefox browser) wants to provide support for Webkit’s -webkit- prefix (that is used by browsers like Safari and Chrome that use the Webkit engine). A lot of people are saying this is a bad idea. Others are also saying we (the designers/devs) have gotten ourselves into this mess. I think it really comes down to all of us – the browser vendors, the W3C, and the web designers/devs.

The browser vendors have their own set of prefixes that they use for experimental purposes – it is pre-standardized code, and prefixes are not spec. Firefox uses -moz-, Safari and Chrome use -webkit-, Opera uses -o-, and Internet Explorer uses -ms-. Apparently, web designers/devs are using the -webkit- prefixes only, to use properties we call “CSS3″, because they either don’t know about the equivalent prefixes for other browsers, or don’t bother (sometimes, though, they don’t exist). Technically, some of these fancy schmancy techniques we use with prefixes aren’t really CSS3 – yet, anyways depending on how far along they are towards W3C recommendation. Many of these techniques are kind of like previews, and allows the browser vendors to test stuff out (as well as designers/devs too, who can provide feedback). Some browser vendors are already supporting standardized CSS3 properties. But the support varies with each browser vendor, and some browser vendors are using their prefixes to test things, and not all are testing the same things.

Part of the problem, that other people have brought up, is the browser vendors should use these prefixes only in non-production releases. I agree that really, really, experimental properties shouldn’t be in production releases, because I think that’s where issues arise if they are used for production websites. But I think those prefixed properties that work great (no bugs, etc.) should be available so that designers/devs can play with them now, even in production websites. And, the browser vendors should submit implementation reports so that the way they are implemented could potentially be the standard in the W3C specification.

So because we can, designers/devs are using these prefixes to enjoy using these fun CSS3 properties now. What Mozilla has a problem with, is designers/devs are using only the -webkit- prefix, and nothing else. That means any fancy tricks that are showing up in browsers that support the -webkit- prefix will show up… but not for the other browsers, such as Firefox. So they want to support the -webkit- prefix (which other browser vendors like Opera and Microsoft might be eyeing at now) so that websites viewed in their browser looks just as good.

I think that’s where a BIG part of the problem really lies. It’s with the designers/devs. Personally, if I am going to use some sort of CSS3 technique, I use all the available vendor prefixes, and put the W3C spec version at the bottom of the stack as a fall back in hopes that all browsers will support the spec version one day (though it will probably be awhile before we can not use any vendor prefixes at all, as older browser versions will still need the prefixes).

Why are designers/devs not using stacks for CSS3 properties? We use font stacks. Why is this different?

It could be lack of time to test in other browsers for projects that are on a tight deadline. It could be laziness. Whatever the reason, it needs to stop.

I use stacks for CSS3 properties so that they work in as many browsers as possible, but also in the hopes that eventually we will be able to just use the spec version one day – future-proofing! And it only takes an extra minute, if that, to support the other browsers. I also don’t use extremely experimental properties, or ones that only work in some browsers (unless it degrades nicely… I don’t want weird stuff going on).

Then, that is where we have to look to the W3C. Css3 has been split into different modules (you can see how far along each module is at Css3.info). Many are still in Working Draft, and the process can be slow. It is great that the modules are split however, so that they can all progress at different rates, but it is still a very slow process, especially since CSS 2.1 isn’t even at full Recommendation yet.

So I think in the end, it comes down to all of us working together. The W3C needs to work at moving things along a little faster if they can, because we’re all itching to use these new CSS properties. Browser vendors should stick to their own prefixes, work at making them better so we’ll want to support them, and start to support more new CSS properties as they become spec. And most importantly, as professionals, web designers and developers need to support ALL browsers as best as possible, and use the spec version at the bottom of the stack. We need to provide a fall back for older browser versions, and future-proof our work too.

As Kevin O’Leary would say… stop the madness!