Using active callbacks in the Customizer

One thing I haven’t seen many themes use is active callbacks to their advantage. What are they and how can they used? It’s actually quite simple and there are two methods that the customizer has available. The first one is when you first create the section, panel, or control.

$wp_customize->add_section( 'meta-slider-section',
	array(
		'title' => __( 'Meta Slider Section', 'jc-domain' ),
		'description' => __( 'Input the ID of a slider and it will display on this section of the theme', 'jc-domain' ),
		'active_callback' => 'is_meta_active',
	)
);

Great! We have a section but how do make sure that it will only be seen when the plugin is active? The 'active_callback' function will be used. In that function we can setup our logic so that the section will only show if the meta slider plugin is active.

function is_meta_active(){
	// Check for the slider plugin class
	if( !class_exists( 'MetaSliderPlugin' ) ) {
	// If it doesn't exist it won't show the section/panel/control
		return false;
	} else {
	// If it does, we do show it
		return true;
	}
}

Fairly neat right? What’s really awesome is that you can do this with controls as well. Let’s say we want a control to only show with a specific page template. You can use the callback function to look something like:

function is_certain_page_template() {
	// Get the page's template
	$template = get_post_meta( get_the_ID(), '_wp_page_template', true );
	$is_template = preg_match( '%fullwidth.php%', $template );	if ( $is_template == 0 ) {
		return false;
	} else {
		return true;
	}
}

Now, I mentioned there are two methods of using active callbacks. The second method is by using an extending class. Let’s say we have a custom control class that we only want to show when an option is selected.

Now, I mentioned there are two methods of using active callbacks. The second method is by using an extending class. Let’s say we have a custom control class that we only want to show when an option is selected.

if ( class_exists( 'WP_Customize_Manager' ) ):
class JC_Manic_Control extends WP_Customize_Control {
	function active_callback(){
		// This is the function that will house the logic so our control
		// shows only when we need it to. This will override the
		// WP_Customize_Control's active_callback function.
		return false;
	}
	function render_content(){
		// other code goes here, keeping it simple for demonstration purposes.
	}
}
endif;

Pretty darn cool if you ask me. Now, with those two methods you can create a much better experience with your theme options and customizations. So, go on and explore and experiment with active callbacks. Add it to your repertoire of theme tools and WordPress knowledge!

Fun with template tags: comments_template

On my last post I talked about dynamic_sidebar and some uses. It was a fun little experiment I wanted to do and share. Yes, I said experiment. That is how I learn. I read, do and then share. I know I’m not the only one that does that.

This time I dabbled with comments_template(). Yes, another one of the more common template tags. I wanted to dissect the function and see what really makes it unique. Okay, not really, I more or less wanted to look at the code and see how it gets the template file.

Core code

The code itself is about 90 lines. That is including the inline documentation. Without the inline documentation it is about 60 lines. Good to know. It means we don’t have to guess what is going on a lot. So let’s dive in shall we?

Okay, let’s break the function down, shall we?

The arguments

The first argument that is passed is the $file location. The second is whether or not to separate the comments. Simple. But what does that mean and how can we change this?

One way, of course is by passing some arguments ourselves. Let’s say we wanted to separate the comments, we would use:

<?php comments_template( '', true ); ?>

Or if we had our comment template in another location we would use:

<?php comments_tempate( '/inc/comments.php' );

That’s great if your comment template resided in the inc folder and was named comments.php. But what happens if you don’t have a comments.php file anywhere in your theme’s folder? Well, the nice part is that WordPress does account for that. The downside is that it creates a deprecated_file call. Yes, an error. If you read the following doc-block you can see why.

/**
 * @package WordPress
 * @subpackage Theme_Compat
 * @deprecated 3.0
 *
 * This file is here for Backwards compatibility with old themes and will be removed in a future version
 *
 */

I’m going to emphasize the part that really matters most:

and will be removed in a future version

Backwards compatibility is one thing that WordPress does really well; though this is one time I wish it would do it faster. At least for these files. There are a few other files but I’ll focus on this for now.

But why does it load that file if there is no comments.php file? Let’s look a little closer at what the function actually does. At least the parts that really make it load the needed file.

if ( empty($file) )
	$file = '/comments.php';

$theme_template = STYLESHEETPATH . $file;

$include = apply_filters( 'comments_template', $theme_template );
if ( file_exists( $include ) )
	require( $include );
elseif ( file_exists( TEMPLATEPATH . $file ) )
	require( TEMPLATEPATH . $file );
else // Backward compat code will be removed in a future release
	require( ABSPATH . WPINC . '/theme-compat/comments.php');

Not really much code, right? First it checks if the passed argument $file is empty and if it is it creates a simple string of '/comments.php'. Then, it creates a variable $theme_template with the constant TEMPLATEPATH and $file appended to it. Next we see a fairly familiar function apply_filters(). The filter name is comments_template.

We can then use a filter hook to change the location of our comments template. Granted we can do the same without even using the filter by simply passing it the location string to the function itself as we saw above, right?

It matters

Why am I bringing this up? I am bringing this up because the comments template file should be the place to be using wp_list_comments() as well as comment_form(). It doesn’t have to be comments.php that houses those template tags. It could be named anything you want, you just have to make sure you are loading the file properly.

Using a filter

One way is using a filter hook. As you noticed above the line:

$include = apply_filters( 'comments_template', $theme_template );

This what we can use. The code would look a little something like:

add_filter( 'comments_template', 'demo_path_to_comments_template' );
function demo_path_to_comments_template( ){
	if ( is_child_theme() && file_exists( get_stylesheet_directory() . '/inc/coms.php' ) ){
		return get_stylesheet_directory() . '/inc/coms.php';
	} else {
		return get_template_directory() . '/inc/coms.php';
	}	
}

Yes, quite a bit just for comments, right?

Using an argument

What’s super cool about using the core template tag and passing it the argument is that it will first look in the child theme ( if active ) and then the parent theme for the file you designate.

<?php comments_template( '/comments/pings.php', true ); ?>

In the above example it will first look for the pings.php file of the child theme ( if it is active ) and if that file does not exist it will load the parent file. Sort of what get_template_part() does. That is another neat little function for another post.

Seriously, it matters

I’m going to repeat this part because it bears repeating. The backwards compatibility file will one day be removed. Your users will thank you for not using the fallback file. It shouldn’t be a safety net for the theme. Besides, if you want the theme to be hosted in the repository it can’t have any errors.

Fun with template tags: dynamic_sidebar

The last couple of weeks I’ve been reading the core code more and more. I like it. Came to the conclusion I really don’t know every hook or filter. I don’t claim to though. I like knowing enough to make a functional theme or even a plugin. Yes, I’ve been recently dabbling with one but that’s for another post.

The reason for this post is to share some knowledge. Hopefully somebody finds this useful or helpful.

The function

For this post I will be using dynamic_sidebar(). It’s a fairly common template tag in themes. It gets a widgetized area and outputs them in a designated area. In order for that to happen you must first have a registered area. We do that by using register_sidebar(). For demonstrational purposes we will use:

register_sidebar( array(
	'name'          => __( 'Footer Area', 'dademo' ),
	'id'            => 'footer-area',
	'description'   => __( 'Add widgets here to appear in your sidebar.', 'dademo' ),
	'before_widget' => '<aside id="%1$s" class="widget %2$s">',
	'after_widget'  => '</aside>',
	'before_title'  => '<h2 class="widget-title">',
	'after_title'   => '</h2>',
) );

Great! So we created a widgetized area with an ID of footer-area. It can be anything we want but we will currently stick to simple naming conventions. Now, let us look at the core code, shall we?

The core code

The function itself is quite a few lines of code. Approximately 160 lines. I’m not going to post all of that code. The developer reference page has it and you can even view on trac. The ones that matter most for this post are two lines.

The first line:

do_action( 'dynamic_sidebar_before', $index, true );

The second line:

do_action( 'dynamic_sidebar_after', $index, true );

Notice something a little strange about it? I’m referring to the $index part of course. This is the neat part of it all. What does that little part mean?

Our hook

The cool part is that you can hook to specific widgetized areas if you want. I know you may be asking what I mean by this so I’ll demonstrate a little bit. Take our previous example of footer-area above and we will wrap it within a <section> element tag with a class of row.

add_action( 'dynamic_sidebar_before', 'demo_sidebar_before' );
function demo_sidebar_before( $index ){
	if ( $index == 'footer-area' ){
		echo '<section class="row">';
	}
}
add_action( 'dynamic_sidebar_after', 'demo_sidebar_after' );
function demo_sidebar_after( $index ){
	if ( $index == 'footer-area' ){
		echo '</section><!-- Widgetized footer area -->';
	}
}

From there it would render:

<section class="row">
	<aside id="recent-posts-4" class="widget widget_recent_entries">
	<h2 class="widget-title">Recent Posts</h2>
	<ul>
		<li>
		<a href="/2015/04/13/aesop-testing/">Aesop testing</a>
		/li>
		<li>
		<a href="/2015/04/13/sampling-some-code/">Sampling some code</a>
		</li>
		<li>
		<a href="/2015/04/08/another-gallery/">another gallery</a>
		</li>
		<li>
		<a href="/2015/04/08/gallery-7/">gallery 7</a>
		</li>
		<li>
		<a href="/2015/04/08/gallery-6/">gallery 6</a>
		</li>
	</ul>
	</aside>
</section><!-- Widgetized footer area -->

As you can see it created the section element and inside of it is a simple recent posts widget. Now, as I mentioned that is for specific widgetized areas. The thing to remember is to use the ID of the widgetized area to conditionally add or remove. It is that $index that is used to test. You can add things to every single dynamic_sidebar call by not even checking. Let’s say we have two widgetized areas. One in the footer and the other just above the content. We will call that section, “content-above.”

I know, very creative. I said it would be simplistic, didn’t I?

Okay, we wanted to add few things. Let’s say we wanted to add an image to both of those sections. We could edit two different files depending on how your theme is structured. Sounds a little painful, right? So, we will use our handy-dandy little hook:

add_action( 'dynamic_sidebar_before', 'demo_sidebar_before' );
function demo_sidebar_before( $index ){
	echo '<section class="row">';
	echo '<img src="' . get_template_directory_uri() . '/img/divider.png" />';
}
add_action( 'dynamic_sidebar_after', 'demo_sidebar_after' );
function demo_sidebar_after( $index ){
	echo '</section><!-- Widgetized area with image -->';
}

Pretty cool, right? What’s super cool is it will render like:

<section class="row">
<img src="path/to/img" />
<!-- widgets -->

</section><!-- Widgetized area with image -->
<section class="content row">
<!-- the_content -->
</section>

<section class="row">
<img src="path/to/img" />
<!-- widgets -->
</section><!-- Widgetized area with image -->

Yes, all that markup where ever you are using dynamic_sidebar().

Advanced fun

This part I’m writing as my left eye is twitching only because it deals with widgets in themes. Yes, I’ve never liked including them. This part deals with hooking to particular widgets in your theme.

Yes, you could simply edit the file that has the widget but where is the fun in that? This time we will use an action hook.

add_action( 'dynamic_sidebar', 'demo_sidebar' );
function demo_sidebar( $obj ){
	
	if ( $obj['callback'][0]->id_base == 'meta' ){
		printf( '<span>%s</span>', __( 'So much meta', 'dademo' ) );
	}
	// Alternatively
	// if ( preg_match( '/meta-/', $obj['id'] ) ){
	//	printf( '<span>%s</span>', __( 'So much meta', 'dademo' ) );
	// }
}

Does look a little complex, right? Let’s break it down a little.

First, we create the hook in line 1. Then we create our callback function in line 2. Doing good so far. Line 3 is where it does get a little odd. What does it mean? What does it mean?!

Okay, it may look a little complex to some but I’ll explain a little bit more.

When using dynamic_sidbar() it uses an array for the widgets. If there are no widgets then the function returns a false value. If there are it creates an associative array of the widget instance. That array is what we pass our callback function. In the example it is called $obj. In that array we have a key called callback. It, too, is an array.

We are looking for the first item on there because it holds the important part. The information about the widget object. The example is looking for the id_base of the widget. You know that little part you named when you registered the widget.

The alternative uses preg_match to match the ID of the widget’s instance. Yes, you can do specific instances as well.

Displaying multiple pages on one

Every so often I come across a theme or an implementation I like and wonder how it is being done. I like to dig behind the scenes on themes and see how they do things. Taking things apart to see how they work is a great way to learn.

One neat little tidbit I learned was how to create a page template that can use content from other pages and append it.

The steps

  1. Write code
  2. ???
  3. Have a celebratory drink

Step 1: Write Code

Yes, we will be writing quite a bit of it. Okay just enough to get the ball rolling and demonstrate the concept. One of the first things we need to do is figure out how many pages we want to show on our page template. I’ll use a smaller number like one to get started. You can add more if you want but because this is for demonstrational purposes we’ll keep it nice and simple.

So first, we will create our setting in the customizer:

$wp_customize->add_section( 'my_theme_page_sections', array(
	'title'    => __( 'The first page', 'text-domain' ),
	'priority' => 130,
) );
$wp_customize->add_setting( 'my_theme_page_1', array(
	'default'           => '',
	'sanitize_callback' => 'my_theme_sanitize_dropdown_pages',
) );
$wp_customize->add_control( 'my_theme_page_1', array(
	'label'             => __( 'Page 1 content', 'text-domain' ),
	'section'           => 'my_theme_page_sections',
	'priority'          => 30,
	'type'              => 'dropdown-pages',
) );
// the sanitize callback
function my_theme_sanitize_dropdown_pages( $input ) {
	if ( is_numeric( $input ) ) {
		return intval( $input );
	}
}

Next, we can create our actual page template.

/**
 * Template Name: Multiple pages
 *
 */
get_header(); 
	while( have_posts() ) : the_post(); // beginning of the loop
		// The page content of the selected page.
		// something basic can work like 
		the_content();
		wp_link_pages();
	endwhile; // end of the loop
	// Here is where the fun part is!
	rewind_posts();
	my_theme_selected_pages();
get_footer();

Yes, I’ve left out a lot of the markup but that’s only because the styling will be different for everyone. As you can see the part that creates the extra content is the function my_theme_selected_pages. That means we have to create this function somewhere. It can look something like:

$page_1 = intval( get_theme_mod( 'my_theme_page_1', '0' ) );

if ( 0 == $page_1 ){
	return;
}

for ( $number = 1; $number <= 2; $number++ ):
	if ( 0 != ${'page_' . $number} ) :
		$selected = new WP_Query( array( 'page_id' => ${'page_' . $number ) );
		// Our newly created loop with our selected page(s)
		while( $selected->have_posts() ): $selected->the_post();
			the_content();
			wp_link_pages();
		endwhile;
		wp_reset_postdata();
	endif;
endfor;

As you can see I have made it super simplistic. You can add more pages if you want. The key is making sure that $number<=2 matches the right amount of pages you want to add. So if you wanted to add five you would change the 2 to a 5. Yes, I left it at two because I forgot to change it.

Step 3: Celebrate!

Okay, maybe style it up if you want but I’m going to celebrate with some coke zero.

Making a Portable Object Template for your WordPress theme or plugin

Yes, a bit of a lengthy title but I feel will get the point across and it is after all what I’m wanting to share with you today.

A what now?

A .pot ( or a Portable Object Template ) file is what WordPress uses and many PHP programs use for translation purposes. There are three files used. According to icanlocalize.com the files are:

  • MO – Machine Object. The MO file includes the same contents as PO file. The two files differ in their format. While a PO file is a text file and is easy for humans to read, MO files compiled and are easy for computers to read. Your web server will use the MO file to display the translations.
  • PO – Portable Object. This is the file that you receive back from the translators. It’s a text file that includes the original texts and the translations.
  • POT – Portable Object Template. This is the file that you get when you extract texts from the application. Normally, you send this file to your translators.

The one we will worry about is the last one. The POT file. There are several ways to create this file but the one I’ve found most useful was the one Otto was awesome enough to post for theme reviewers. It is super simple and does need a little tinkering and getting over the fear of the command line.

Yes, the command line. You know that little program that uses only text. No, not a text editor. Would be cool but no. Depending on the platform you are using it will be called a terminal window, command prompt or even powershell. All of these will work for what we will be creating.

Steps and requirements

Sorry, did I not mention there would be some requirements? The basic requirement is the command line and having PHP installed. The next would be getting the needed files from the repository. If you aren’t developing themes using a development version of WordPress leave your address in the comments below, I will find you and I will hit you. Hard. Even a release candidate is worth your investment unless you like to break things and have people yelling at you.

The tools and files you will need are in one of two locations. The first being in the svn developer site. You will need some sort of SVN software in order to get it, of course. The other would be from my github repo I created and modified. Yes, I created it just for this reason.

So the steps are as follows:

  1. Get files
  2. Extract files to correct folder
  3. Open command line
  4. Do some magic – or Voodoo, your choice
  5. Do happy dance!

Getting the correct files

I mentioned and linked two places where to get the needed files. The github link is the one I will go over. Part of that reason is not everybody will be fully familiar with version control or comfortable enough to not break things. Once that is downloaded we can open the zipped folder and move on to the next step!

Extracting the files

This is super simple thing to do. Extract the files to the root of your WordPress folder. It should look something like the image.

WordPress folder
WordPress folder

Open the command line

Now, there are several tools that are available for this. For Windows user there are two that I will often switch between: command prompt and powershell. I like using powershell more. We then will change to the directory where we have our WordPress installation.

For the next step will be going over some code, so be prepared.

Doing the magic

So here is where the real magic will happen. Once we are in the folder of our installation we will once more change directories to the i18n folder where all translation files reside. From there we will run a quick line of code that will create our new POT file.

$ php makepot.php wp-theme /path/to/theme /path/to/languages/theme-slug.pot

The thing to keep in mind is the $ is just a placeholder for the current directory you are in. It may differ from machine to machine. Once we have run that it will create a new file ( theme-slug.pot ) with all translation-ready strings. So try not to forget to translate all text strings!

How it works

I know there are a few people wondering how this actually works. I know I was for bit. I’ll try my best to make it a little more understandable why you need to have certain things in your command line.

The first thing you need to know is what you are doing. When you state php you are to a degree saying, “I want to run PHP code and use this file.” The next three things are what you are going to pass that file.

  1. The first thing we passed is what type of project you are creating the pot file for. In our case it is a wp-theme. There are a few other you can decide from like wp-plugin, wp-admin, wp-core and a few more that I just won’t list.
  2. The second thing we passed is the location of where to look for the translation functions. If you read through the list of what functions it looks for you are in for a treat because that list you can add to Poedit. (I’ve slowly walked away from that but would still recommend for beginners.)
  3. The last thing is the output of the file. Both the location and the name ( be sure to include the extension as well ) are what we will be using.

Now, you can do this with your plugins as well. Just be sure that the folder you are creating the POT file to does exist otherwise you will get errors and it won’t create the file for you.

I stated earlier that it works with a few changes; it’s true. The reason being I know there are some people who don’t like to use a development version of WordPress. Why? I don’t know but I made a few tweaks for it to work the way it works. Okay, I only changed three things but it works for the time being. I say that only because I’ve tested it on/off since the original post. If you encounter any issues please be sure to let me know!

Celebration will begin

There we have a newly created POT file ready to be sent to a translator. So, yes, by all means do your happy dance. Not only did you get over the slight fear of the command line but you possibly learned something new along the way.

Notes

If you don’t specify a path of where your theme/plugin resides it will create an error and will not work!
If you don’t specify a path, just a name for the file it will create the file in the i18n folder.

Child theme friendly post-formats

It’s no surprise I will always preach the making of child themes. Part of the reason is because you can make modifications without losing all that when it comes time to update the parent theme. I mean nothing more exciting than having to recall what files you changed, what code you added, deleted to brighten your day. Troubleshooting. It’s amazing.

The dilemma

Currently the biggest issue I’ve really seen is post formats. It’s not really easy to add to the parent theme. I mean yes and no. Adding to the list is not entirely possible without some parent theme editing and that is what I actually did. I created a quick function that checks and adds to the list of post formats.

The code

function get_theme_post_formats(){
    // $core_formats = array( 'link', 'chat', 'quote', 'gallery', 'status', 'image', 'aside', 'audio', 'video' );
    // base support for the theme
    $formats = array();
    // child if it wants to add
    $child_formats = apply_filters( 'theme_post_formats', array() );
    foreach( $child_formats as $key => $format ){
        if( ! array_key_exists( $format, $formats ) ){
            $formats["$key"] = $format;
        }
    }
    return $formats;
}
add_theme_support( 'post-formats', get_theme_post_formats() );

How it actually works is pretty nifty. What those fourteen little lines of code does is create a filter for child themes to use. That filter is: theme_post_formats. What you would do in the child theme’s function file is something like:

add_filter( 'theme_post_formats', 'child_formats' );
function child_formats(){
    return array( 'link', 'status', 'gallery' );
}

What that will do is add to the list of post formats of the parent theme. The way WordPress core makes you do it is by re-declaring the formats. What I mean by that is you have to call the function add_theme_support and list the already supported formats and add. Seems like a little too much work for some. At least how I feel about it; some may or may not agree with that.

To show you what I mean:

// Parent theme declaration
add_theme_support( 'post-formats', array( 'link', 'gallery', 'quote' );

// Child theme declaration
add_theme_support( 'post-formats', array( 'link', 'gallery', 'quote', 'status', 'chat' );

As you can see both can work. What it boils down to is how you want people to extend to your theme.

Dealing with menu items

I feel as though this subject is a bit different than what I’m used to.

To a certain degree it is. I’ve never really dabbled much with the menu class within WordPress. I mean I used the wp_nav_menu template tag once or twice but never really looked as to how it works. That was until a few days ago when I saw something that really made me wonder. I had to ask myself the question of how to do it.

I, of course, turned to Google and looked for a tutorial or two. That was after I looked at the code for the menu class. ( Which can be found in the wp-includes folder )

I’m not going to lie when I say that I was a little confused by the code. The main reason being that it is so much of it. That and I really just skimmed it rather than actually tried to process the code. I know. I know. I need to read the code.

The reason

I bring this up because when I saw those little words on my computer screen I really had to do a bit of a double take. I had to look up and see if any theme had support for a menu description. Throughout all the themes I’ve had a chance to review and all the themes I’ve come across I don’t think I ever really got a chance to experiment with that feature.

Yes. A feature. As it turns out not many themes are able to–or do really–have that support.

How?

I wondered about how I could do this without having to deal with a lot of code. After all it should be simple.

Right.

At least I like to think so. I did some reading and some experimenting and I wanted to share some information.

The method I liked best.

I mean, after all, in WordPress there are several ways of achieving the same result. The one I want to share is a really simple one. All you are adding is about eight lines of code. Very simple, right?

So here goes.

class Descriptive_Menu extends Walker_Nav_Menu {
    function end_el( &$output, $item, $depth = 0, $args = array() ) {
        if ( $item->description ){
            $output .= '<span class="menu-description">' . $item->description .'</span>';
        }
        $output .= "</li>\n";
    }
}

Seems a little odd? Not really.

Let’s walk through what it is doing, shall we?

The first line is actually extending the Walker_Nav_Menu class and we are really doing is appending a span tag just before the end of the list item ends. But we are only doing that if there is a description available.

In order to have a description you go to the Menus screen, expand the screen options and make sure you have “Description” selected under the “Show advanced menu properties” section.

Now, in order to show it you will have to add one minor thing to wp_nav_menu. In the array you will want to add:

'walker' => new Descriptive_Menu()

So go on. Try it out. Experiment by extending certain parts of the Walker_Nav_Menu like start_lvl, end_lvl, or even start_el.

So you want to become a WordPress Theme Reviewer?

What does it take?

Some PHP, JavaScript, HTML, CSS knowledge and a little bit of time to spare. At least that is what it takes to get the ball rolling.

Yeah, very simple. Doesn’t take much really.

The basics

There are some things that you really have to know in order to becoming a WordPress Theme Reviewer. Here is a quick list I feel makes for a good theme reviewer.

  • Knowledge
  • WordPress prowess
  • Personality
  • Time
  • Communication

Now, that is what makes for a reviewer but how to get your foot in the door?

Those steps are a little bit easier. One of three ways to get started really. The first one is by requesting a ticket to review from the review queue. [note: it is as of this writing]

The second way is by emailing the theme reviewers mail list and asking if any new theme is available for a review. Keep in mind that you will have to subscribe to that list as well in order to keep in contact with all theme reviewers and admins. You can also follow a good few through twitter, personal blogs or however you’d like.

The third way, but is less frequently checked, would be through the IRC channel #wordpress-themes. They will also link you to the review queue I mentioned earlier so these last two would be just pushing it if you did all three. Just saying.

What next?

The next step would be to setup your testing environment. Getting all the needed information, the settings and finally testing the theme. How you set that up is entirely up to you but there are some things that must remain the same across all the testing platforms. Can you guess what that is? It’s a simple setting that will help solve some of your headaches.

It is setting WP_DEBUG to true in your configuration file. Yeah, a very simple thing, right? Keep in mind that there are other ways to keep track of errors as well.

As far as plugins go, there are plenty to pick and choose from. The widely accepted one is the developer plugin by the Automattic team. It is a great plugin to get you started in creating a theme or plugin.

Testing

Yeah buddy! Finally we can discuss testing the theme. In order to test a theme you need data. Enter the theme unit test file. There are a few places that have some sample posts and images that you can download. Just a simple XML file that you import. Thankfully there is one that is widely used by many theme reviewers. The file stays up to date and is looked over every once in a while for errors.

An alternative is to use your own posts if you have enough. I may one day try creating my own little set of posts but for now I use the theme unit tests provided. It’s convenient if you are just starting out.

Unit Testing

Simple. Follow the steps provided in the theme unit test page and then report any major errors in the theme’s ticket.

Go through each scenario and make sure you write any, and all errors that you encounter. Keep in mind that is only part of a review. There is one part that I feel is extremely important. Communication.

Let’s talk about it

Yes. Talking is the single biggest thing when you are reviewing a theme. Without talking to the theme developer neither one of you is learning or even progressing. I mean it. Keeping in touch is the key to becoming a good theme reviewer as well as a developer.

A great example of this would be a ticket I reviewed nearly four months ago. I assigned myself the ticket, looked over the code, tested to see if anything would break and took note of it all. I posted the required things that needed to be addressed in order for the theme to be approved.

I didn’t hear any response from the developer in three days. I posted a question asking if they needed more time. Still no response. Nearly a week later I told that person I had to close the ticket and not approve the theme. About a week ago I was on the support forums and saw that somebody had a question about the theme and if there would be an update, if any. Made me sad to see that.

Personality?

Yes. It does take a certain personality to be a good theme reviewer. At least I think so. The reason I say this is because as a theme reviewer you are helping somebody. You are helping them share something with the world. I know it does sound a little cheesy but it is true. Think back to when you were in school and you had to create something for a class project. Odds are there was at least one person in that classroom that got all the recognition and all the praise for going above and beyond what the project asked for.

Now put yourself in their shoes ( if you weren’t already that person ) and think about how it feels. It feels good. It makes me happy approving a theme. At least one that I feel is worthy of approval but that’s another topic.

Think you can?

So, you ready to become a theme reviewer? If so, then head over to the Make Theme blog, give some input, ask for a ticket and give back to the community!

Choosing the right path

It’s no secret that I love using WordPress and love design. Those are pretty obvious if you’ve known me for some time. I guess you could say I’m a little addicted to WordPress. My digital meth if you will, but I also love design about the same.

Working on WordPress themes is an amazing middle ground for me. It’s almost a zen state for me when I’m looking at a design and trying to figure out how to code the theme. Some themes require a little more TLC than others. A great example is when you have to think about the end user. As some may, or may not, know I like to help out in the WordPress.org support forums when I can.

I’ve even written a post about creating a child theme. Yes, I do encourage that in the forums as well if you want to make any modifications to any theme. The downside is that often times some themes don’t generally like to use: get_stylesheet_directory_uri()

Dilemma

Now, there are two things to remember when it comes to working with child themes.

  1. Use them
  2. Code properly for them

What I mean by number two is that you should be using the right function when it comes to enqueuing the stylesheets and scripts. In this case I’ll be talking about stylesheets.

A few days ago I was typing out some code for my theme and started to think about the structure of my folders. The most commonly used in themes seems to be to have all the CSS files bundled together and all the JavaScript files together as well. Simple and makes sense really. The downside is when some people use a stylesheet that resides in that folder. It does seem a little odd but it will all make sense in a bit.

The issue is when a parent theme uses the rule

@import url( 'path/to/stylesheet.css' );

in the main stylesheet. What that means is that the user now has to look for the location of the main stylesheet and create the right code for it. Or better yet have to include the

@import url( '../path/to/parent/stylesheet.css' );

rule in the child theme.

Why not make it a little easier for them?

How?

By using a quick conditional check to see if the current theme is a parent theme or a child. Yes, there is a function for it. Believe or not it is actually:

is_child_theme()

Simple little function that checks to see if the stylesheet path and the template path are the same; if they are then it is a parent theme, otherwise it is a child. Quick and painless, right?

But how to use it to our advantage? Easy. When we register our scripts and styles we add on the little conditional and when it is a child theme we use both the child’s stylesheet as well as the one being used by the parent.

if ( is_child_theme() ){
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/css/mite.css' );
    wp_enqueue_style( 'child-style', get_stylesheet_uri() );
} else {
    wp_enqueue_style( 'parent-style', get_stylesheet_uri() );
}

You’ll notice that I am using two different functions when it is a child theme to enqueue the stylesheets being used.

The main reason for this is that when the function

get_stylesheet_uri()

is used it will get the location of the stylesheet of the active theme. We don’t always want that because if you are the a developer that likes to group their files accordingly then it may just lead to a little trouble.

With that little snippet you can now rest assured that when you activate the theme it will load the right path. Now in order for all of this to work we just add one minor thing to our style.css file:

@import url( ../css/theme-style.css );

Fairly straight forward, right?

Creating a custom comment list

What?

Comments. That is the topic. As some may know I’m in the middle of creating a WordPress theme to submit to the repository. I want this theme to not only pass but to pass with flying colors. I followed about as close to how the default themes are but have also integrated some from themes I have reviewed and added a bit of my own style, of course.

What started this?

What really initiated this was the default theme for WordPress 3.6: Twenty Thirteen. Previous default versions all passed a certain set of arguments and made a callback function in order to display the comments rather than have WordPress handle it. Wait? You mean to tell me that I can let WordPress do the coding for me? Yes. If you don’t like having control of how to structure your code. Twenty thirteen lets WordPress handle the coding of the comment list.

Callback?

Yes, a callback function. Simple and you have more control of how the code is structured and displayed. The function that handles this is:

wp_list_comments()

All that is needed now is some arguments:

$defaults = array(
    'walker'            => null,
    'max_depth'         => '',
    'style'             => 'ul',
    'callback'          => null,
    'end-callback'      => null,
    'type'              => 'all',
    'page'              => '',
    'per_page'          => '',
    'avatar_size'       => 32,
    'reverse_top_level' => null,
    'reverse_children'  => '',
    'format'            => 'xhtml', /* or html5 added in 3.6  */
    'short_ping'        => false, /* Added in 3.6 */
);
wp_list_comments ( $defaults );

Now, the thing that creates the comments is the callback. It tells WordPress to run the default code if no argument is passed. If there is one, then WordPress will look for that function and use that instead. In Twenty Twelve it was:

wp_list_comments( array(
    'callback' => 'twentytwelve_comment',
    'style' => 'ol'
     ) );

In the Twenty Thirteen theme it actually uses the default HTML5 markup by not setting a callback function and using the new argument:

'format' => 'html5'

This tells WordPress to use the HTML5 markup for the comment which is:

<article class="comment-body">
 <footer class="comment-meta">
 <div class="comment-author vcard"></div><!-- .comment-author -->
 
 <div class="comment-metadata">
 <a href="">
 <time></time>
 </a>
 <span class="edit-link">Edit</span>
 </div><!-- .comment-metadata -->

 <p class="comment-awaiting-moderation"></p>

 </footer><!-- .comment-meta -->

 <div class="comment-content"></div><!-- .comment-content -->

 <div class="reply"></div><!-- .reply -->

</article><!-- .comment-body -->

Keep in mind that is the very simplified version without any WordPress comment template tags. Just straight HTML5 markup. Some people don’t mind using that while others like to have more control and would like to style in a different way. In order to do that we have to pass an argument to the callback function argument.

Enter the callback

This is why you want to use a callback function to create and style the comment. In order to do this we pass the argument

'callback' => 'my_theme_comment'

in our array of arguments much like Twenty Twelve does. Next we have to create the actual function that will house our newly created and customized comment with custom markup. Where that function resides is entirely up to you.

Once we have created the function we can start with all the markup and comment template tags we so desire. I personally like to keep things fairly simple and just have the comment author, date and text. Often my code looks like:

function custom_comments( $comment, $args, $depth ) {
    $GLOBALS['comment'] = $comment;
    switch( $comment->comment_type ) :
        case 'pingback' :
        case 'trackback' : ?>
            <li <?php comment_class(); ?> id="comment<?php comment_ID(); ?>">
            <div class="back-link">< ?php comment_author_link(); ?></div>
        <?php break;
        default : ?>
            <li <?php comment_class(); ?> id="comment-<?php comment_ID(); ?>">
            <article <?php comment_class(); ?> class="comment">

            <div class="comment-body">
            <div class="author vcard">
            <?php echo get_avatar( $comment, 100 ); ?>
            <span class="author-name"><?php comment_author(); ?></span>
            <?php comment_text(); ?>
            </div><!-- .vcard -->
            </div><!-- comment-body -->

            <footer class="comment-footer">
            <time <?php comment_time( 'c' ); ?> class="comment-time">
            <span class="date">
            <?php comment_date(); ?>
            </span>
            <span class="time">
            <?php comment_time(); ?>
            </span>
            </time>
            <div class="reply"><?php 
            comment_reply_link( array_merge( $args, array( 
            'reply_text' => 'Reply',
            'after' => ' <span>&amp;amp;darr;</span>', 
            'depth' => $depth,
            'max_depth' => $args['max_depth'] 
            ) ) ); ?>
            </div><!-- .reply -->
            </footer><!-- .comment-footer -->

            </article><!-- #comment-<?php comment_ID(); ?> -->
        <?php // End the default styling of comment
        break;
    endswitch;
}

And there we have a custom comment that will be used instead of the default WordPress one.