Visit the official page on WordPress.tv!

Coverage

• WordCamp Seattle by Morgan Kay of Alchemy Computer Solutions
• 5 WordCamp Videos You Should Have Watched by theme.fm

The Problem

The theme should look good with or without the header image. Now, I’ve pretty much fleshed out the design of my theme at this point and I really like how it looks without a header image. The design needs to be modified if this is going to work at all.

The most logical place to put the header would be where the site title, tagline and primary navigation menu are currently displayed. If I inject the image directly above this information the image looks great, but this pushes the site title down by 200 pixels and I really do not like this! Another idea would be to inject the image directly below the primary navigation menu. This doesn’t really look as nice in my opinion. The image seems to look best when it is at the top of my content div. What to do? I have some cake. I want to “eat it too”. I just hope that the cake is not a lie!

The solution that I decided on involves a little bit of logic that will move the title and tagline to the top of the screen if a header image has been defined by the user.

Digging Into Some Code

Here’s a simplified version of a cross-section of my header.php file before I got started. This code demonstrates how the theme should work when no header image is defined. (Only the relevant parts of the template are included.)

<div id="wrap">

	<div id="page">
	<?php
		print '<div id="site-title">' . esc_html( get_bloginfo( 'blogname' ) ) . '</div>';

		print '<div id="tagline">' . esc_html( get_bloginfo( 'description' ) ) . '</div>';

		wp_nav_menu();
	?>

To add a header image that looks acceptable to me, I would need to adjust the code to look like this:

<div id="wrap">

	<?php
	print '<div id="site-title">' . esc_html( get_bloginfo( 'blogname' ) ) . '</div>';

	print '<div id="tagline">' . esc_html( get_bloginfo( 'description' ) ) . '</div>';

	wp_nav_menu();
	?>
	<div id="page">
	<?php
		printf(
			'<div id="header-image"><img src="%1$s" width="%2$s" height="%3$s" alt="%4$s"></div>',
			esc_url( get_header_image() ),
			esc_attr( HEADER_IMAGE_WIDTH ),
			esc_attr( HEADER_IMAGE_HEIGHT ),
			esc_attr( get_bloginfo( 'blogname' ) )
		);
	?>

Notice that all of the code inside the #page division has been moved outside and replaced by code to generate a header image.

Technically, I have two unique versions of header.php at this point which needs to be dealt with. But what to do? Initially, I thought that I could add an option to allow user to choose the header template to use. I could even make one of those fancy template selectors like I’ve seen in Genesis and the Options Framework. Depending on which template the user chose, I could load a different version of header.php. Maybe I could create a custom header-image.php to help facilitate this.

Whenever I get the idea of adding an option to a theme, I really take a look at the situation and ask myself if it is really necessary to do so. Most of the time I am able to talk myself out of it. This shown itself to be one of those times.

Two Templates Bad. One Template Good.

I decided that adding a bit of logic to one header.php would probably be a better solution. Here’s a breakdown:

Get some info

To make a decision we will need to know if the user has defined a header image. This is very easy to do. We will use WordPress core function get_header_image(). This function will return a url to the header image if one has been set. If not, it will return an empty string. The first step is to store this the return value of this function in a variable.

<div id="wrap">

	<?php
		$header_image = get_header_image();
	?>

The next step is to determine whether the site title, tagline and primary navigation menu should be printed outside of the page division. We decided above that this should only happen if a header image has been defined by the user. We can easily test for a non-empty value:

<div id="wrap">
<?php
	$header_image = get_header_image();
	if ( ! empty( $header_image ) ) {
		print '<div id="site-title">' . esc_html( get_bloginfo( 'blogname' ) ) . '</div>';

		print '<div id="tagline">' . esc_html( get_bloginfo( 'description' ) ) . '</div>';

		wp_nav_menu();
	}
?>

We’ll need to add a second conditional statement inside the page div as well. If the user has defined a header image we want to print the code to display that image. If not, we will need to print site title, tagline and primary navigation menu as they will not be printed above the page division when no header image has been defined by the user.

<div id="page" class="contain" role="document">

<?php
	if ( ! empty( $header_image ) ) {
		printf(
			'<div id="header-image"><img src="%1$s" width="%2$s" height="%3$s" alt="%4$s"></div>',
			esc_url( get_header_image() ),
			esc_attr( HEADER_IMAGE_WIDTH ),
			esc_attr( HEADER_IMAGE_HEIGHT ),
			esc_attr( get_bloginfo( 'blogname' ) )
		);
	}
	else {
		print '<div id="site-title">' . esc_html( get_bloginfo( 'blogname' ) ) . '</div>';

		print '<div id="tagline">' . esc_html( get_bloginfo( 'description' ) ) . '</div>';

		wp_nav_menu( apply_filters( 'nighthawk_menu_args_primary' );
	}
?>

Duplicate Code

The logic works really well and provides the result that I was after, but unfortunately we have now duplicated the code the print the site title, tagline and navigation menu. The following code appears twice:

print '<div id="site-title">' . esc_html( get_bloginfo( 'blogname' ) ) . '</div>';

print '<div id="tagline">' . esc_html( get_bloginfo( 'description' ) ) . '</div>';

wp_nav_menu();

Now, you may be thinking: “Come on Mike, it’s only three lines. What’s the big deal?”. Well, the actual code that I’m curreny using in the theme is much longer and looks a bit like this:

if ( 0 != (int) get_theme_mod( 'nighthawk_display_site_title', 1 ) ) {
	$text = get_bloginfo( 'blogname' );
	if ( ! empty( $text ) ) {
		if ( ! is_front_page() || is_paged() ) {
			$text = '<a href="' . esc_url( home_url() ) . '">' . esc_html( $text ) . '</a>';
		}
		print "\n" . '<div id="site-title">' . $text . '</div>';
	}
}

if ( 0 != (int) get_theme_mod( 'nighthawk_display_tagline', 1 ) ) {
	$text = get_bloginfo( 'description' );
	if ( ! empty( $text ) ) {
		print "\n" . '<div id="tagline">' . esc_html( $text ) . '</div>';
	}
}

wp_nav_menu( apply_filters( 'nighthawk_menu_args_primary', array(
	'container'      => 'div',
	'container_id'   => 'menu-top',
	'menu_class'     => 'menu',
	'theme_location' => 'primary',
	'depth'          => 1,
	'items_wrap'     => '<ul id="%1$s" class="%2$s" role="navigation">%3$s</ul>',
	'fallback_cb'    => '_nighthawk_menu_dialog',
) ) );

It’s about 8 times as long. I really hate repeating myself when writing code, so I needed a solution to deal with this. The first thought I usually have is to bundle it into a function and then call the function twice. This solves the problem of repeated code, but introduces another issue. It’s a PITA to work around. This theme is going to be released to the public and one thing that I know for sure is that people will want to customize it. putting this code inside a function and hiding it away in functions.php is pretty easy to do, but if your users are not comfortable editing php files, chances are they are going to edit php files!

WordPress 3.0 introduced a function called get_template_part() which is a perfect alternative to creating theme functions. In my situation, it is the perfect solution. I moved the code above into a new file which I named top.php and then, in header.php, I included this new file with get_template_part(). My header.php now looks a bit like this:

<div id="wrap">

	<?php
		$header_image = get_header_image();
		if ( ! empty( $header_image ) ) {
			get_template_part( 'top', 'with-image' );
		}
	?>

	<div id="page" class="contain" role="document">

	<?php
		if ( empty( $header_image ) ) {
			get_template_part( 'top', 'no-image' );
		}
		else {
			printf(
				'<div id="header-image"><img src="%1$s" width="%2$s" height="%3$s" alt="%4$s"></div>',
				esc_url( $header_image ),
				esc_attr( HEADER_IMAGE_WIDTH ),
				esc_attr( HEADER_IMAGE_HEIGHT ),
				esc_attr( get_bloginfo( 'blogname' ) )
			);
		}
	?>

Now, my header works as I would like it to, the code is as clean as possible and no code has been duplicated. Good times!

Did You See What I Did There???

If you look closely at each instance of get_template_part() you’ll see that I am passing the optional second parameter which allows you to give content to the template. Since we are using the file in two different contexts – “with an image” and “without an image” – it made sense to do this. “Why?” you ask. Well, this will give the most control possible the the end user. After they install my theme, if they need to customize it, they can easily create a child theme so that the original theme can be updated. If they decide that they do not like the code I have provided in top.php, all they need to do is create their own top.php in their child theme and modify it as they see fit. But creating top.php will change the code that displays both inside and outside the page division. This may or may not be desirable. What if they only want to change the code that displays outside the page division? Since we added context to the template part, this is relatively easy to do. A user can create a file named top-with-image.php. This file will only be called outside of the page division and the theme will use the original top.php when this template is called inside the page division.

Questions? Concerns?

Hope you enjoyed this! I know I was pretty excited when I came up with this solution. If you have anything to add to the conversation, please do so in the comments section.

Once these files were in place I started to look very closely at them to see if there was anything that I could do to make child theming easier for users. I discovered that adding context to all template parts is a very easy thing to do and can allow child themes to modify small sections of a template.

search.php

This is one of the first template files that I added. I wanted to be sure to create a unique presentation of search results. I have always been bothered by themes whose search pages look exactly like their blog views. It was one of my goals to make my theme’s search results appear as if they were generated by a search engine. If you want to see what I came up with, you can search my site and check it out.

Here is a very simplified version of a search.php template:

get_header();
get_template_part( 'loop' );
get_sidebar();
get_footer();

It is relatively easy to override this template in a child theme by copying this file from the parent into the child and then modifying the contents.

But what if the user only needs to change something in the loop? What if they want to define a custom sidebar for use only in search views? It kinda seems silly to have to copy the entire template for such a task.

What I discovered is that all of the functions listed above can take a $name parameter.

get_header( $name );
get_template_part( 'loop', $name );
get_sidebar( $name );
get_footer( $name );

For my theme’s search.php I used the string search for the $name parameter to give the appropriate context that the function is being used in.

get_header( 'search' );
get_template_part( 'loop', 'search' );
get_sidebar( 'search' );
get_footer( 'search' );

Now that the context has been set for each template part function, it is easy to create any of the following files in the child theme to override a small section of the actual template:

1. header-search.php
2. loop-search.php
3. sidebar-search.php
4. footer-search.php

Once I discovered this trick, I wanted to apply it to all of my templates!

single.php

I’ve read many places before that single.php is the template used to display a single post. While this statement is not technically false, it doesn’t really tell the whole story. This file is actually responsible for displaying a single post of any public post_type (except for pages) that does not already have a designated template file. In other words, single.php is a “fallback” template for just about any query that asks for a single post.

Since single.php can be used to display any post_type, I decided that the $name or context parameter should use the post_type of the post instead of the name of the template file. My single.php looks something like this:

/*
 * Capture the name of the queried post_type.
 *
 * Note: It's a good practice to prefix variables
 * with something that will not conflict with other
 * extensions. That is why I used $ghostbird_post_type
 * instead of $post_type here.
 */
$ghostbird_post_type = get_post_type();

/* Use the post_type as the context for each template part. */
get_header( $ghostbird_post_type );
get_template_part( 'loop', $ghostbird_post_type );
get_sidebar( $ghostbird_post_type );
get_footer( $ghostbird_post_type );

This setup allows for a great level of flexibility in child themes. Probably the most useful thing that can be done is to create a unique loop template for each registered post_type:

1. loop-post.php
2. loop-person.php
3. loop-product.php
4. loop-bookmark.php

Had the context been given as “single” (like I have seen many themes do) the only solution here would be to create a file named loop-single.php and then write conditional logic within the loop to render a different format depending on the post’s post_type.

In Conclusion

Adding context to template parts allows a user to affect only small parts of any given template. Some may argue that setting context in get_header() or get_footer() is only helpful is certain situations or “edge cases” and I totally agree! I feel that it important to allow for the greatest flexibility possible for all users. When all is said and done, this may only really help out a very small percentage of your users, but it is very easy to implement and makes extending your theme easier for those who take advantage of this functionality.

<?php
function super_awesome_mega_rad() {
	/*
		Beautiful code that solves all my problems.
		Good job buddy!
	*/
}
?>

But when you open the file and scroll to the appropriate line you see something that looks like this:

<?php
function super_crappy_ultra_mess() {
	/*
		WTF?!?!?!
		Who wrote this crap?
		Oh, I did.
		I DID?!?!?!?!
		headdesk
               grumble ... grumble ...
	*/
}
?>

Personally, this has happened to me more than once and the only thought that goes through my mind at times like these is “What the hell was I thinking?”.

This is a great question that demands to be answered! Providing inline documentation with your code is a great way to answer this question, not only for yourself, but everyone else who uses your theme.

While I was creating Ghostbird, the process of documentation became really, really clear to me and I would like to share my thoughts about the process I use to document my files.

WordPress core uses PHPDoc style syntax to document core and I use it in all my plugins and themes. It’s good to keep things consistent! If you are new to phpDoc, you can read all about it here: http://manual.phpdoc.org/

In the scope of a theme, I found that two types of docBlocks were needed to provide the level of documentation necessary to communicate everything that I wanted. These include page-level docBlocks and function-level docBlocks.

Page Level

I felt that it was important to include a page level docBlock in every php file in my theme. This way I could clearly communicate the intended purpose of the file to the users. I used a subset of available phpDoc tags to accomplish this task. Here’s what I used in my theme’s header.php file:

/**
 * Header Template
 *
 * This file is responsible for generating the
 * top-most html for all public-facing views.
 * It's content is generated via core WordPress
 * functions as well as custom actions defined
 * in functions.php.
 *
 * Child themes are encouraged to work with the
 * actions defined herein to add or remove data
 * to/from the top of the template. In the event
 * that the html needs to be modified, this
 * template may be duplicated inside a child theme
 * and edited there. Please note the this file
 * leaves 2 html div tags open. Both of these tags
 * are properly closed in footer.php by default.
 *
 * @package      Ghostbird
 * @author       Michael Fields <michael@mfields.org>
 * @copyright    Copyright (c) 2011, Michael Fields
 * @license      http://opensource.org/licenses/gpl-2.0.php GNU Public License
 * @since        1.0
 * @alter        1.1
 *
 * FUTURE RELEASE
 * @todo Add widget area. Intended for search form?
 */

Title

More times than not, I just used the name of the file with the extension removed.

Description

In my opinion this is the most important part as it serves to communicate the intention of the file. To figure what to include in the description section for each template file, I did my best to answer the following questions:

1. In which context is the template used?
2. How is the template best modified in a child theme?
3. Does the template use custom hooks?
4. Does the template leave any html tags open that are closed in another template?

Meta tags

@package

This should be unique to your theme. In my opinion, only themes that ship with core should use the term “WordPress” here. Unless your theme is part of WordPress core, you should not use “WordPress” as your package name.

@author

This tag should include your name and, optionally, email address. In the event where multiple authors were responsible for writing code in the document, you can add multiple @author tags.

@copyright

This line should include the name of the copyright holder as well as the year the file was created.

@license

Used to communicate the license that your file is released under. It is a really good idea to include a link to the license as well.

@since

When was the file introduced into the package. This tag should reflect the version number of the theme.

@alter

This tag is not part of phpDoc. Quite honestly, I just pulled it out of thin air. I include this in all of my docBlocks so I can easily tell when the file was last modified.

While it may seem redundant to include all of this meta information in every single file, I feel that it’s better to be as explicit as possible.

Todo tags

The fourth and final section is totally optional but can be especially helpful. First of all, it will show users what you intend to do in the future. If you process all of your source code through a program like phpDocumentor, it will create a list of all todo items for your project … all in a single page! This can be really useful to see what needs to be done for the next version of your theme without having to dig through all the files.

Function level.

Function level docBlocks are used immediately before each function’s definition. While they are similar in appearance to page-level doc blocks, they serve a different purpose: To document the use of a single function. Here’s an example of a function from the Ghostbird theme:

/**
 * Append edit link to content.
 *
 * Certain post formats (aside, link and status)
 * do not display meta information at the bottom
 * of the entry box. While this makes them more
 * compact, it also removes the helpful edit link.
 * This function will add the link inside the_content
 * before wpautop() fires and after the [link] link
 * is appended.
 *
 * @param     string    Post content.
 * @return    string    Custom post content.
 *
 * @access    private
 * @since     1.1
 */
function _ghostbird_content_append_link_edit( $content ) {
	if ( is_single() ) {
		return $content;
	}
	$url = get_edit_post_link();
	if ( empty( $url ) ) {
		return $content;
	}
	$format = get_post_format();
	if ( in_array( $format, array( 'aside', 'link', 'status' ) ) ) {
		$content .= ' <a class="post-edit-link auto-link" href="' . esc_url( $url ) . '" title="' . sprintf( esc_attr__( 'Edit this %1$s', 'ghostbird' ), ghostbird_post_label_singular() ) . '">' . esc_html__( 'edit', 'ghostbird' ) . '</a>';
	}
	return $content;
}

When documenting a function, I visually separate the docblock into four distinct sections. The first two sections are very similar to the page level docblocks and contain:

Title

Most of the time the name of the function (minus the unique prefix) works well here. I try to make this as short as possible.

Description

Quite possibly the most important part. In my opinion, this section should clearly state the intention of the function. Why was it created? If the function is intended to be hooked into WordPress, it is probably a good idea to include this information as well. In the event that the function declares it own custom hooks, the description is the perfect place to let users know how they can customize the function without altering it. phpDoc supports the inclusion of simple html tags, one of which is code. In most of my recent projects, I’ll include mini tutorials complete with code examples which users can copy and paste into their child themes. There is a lot that can be accomplished in the description of a function-level docBlock. I intentionally try to make them as long as possible.

Input + Output

This section is used whenever a function accepts input via parameter and/or returns a value. Two phpDoc Tags are used in this section:

@param

A line starting with the @param tag should be used to document each parameter accepted by the function. These lines should be listed in the order in which they are passed to the function. Each line should contain two pieces of information. The first defines the type of variable that the function expects. The second is meant to describe the data. So-called named arguments (a single associative array whose keys are recognized by the function) present an interesting challenge here. While I would agree that they should be represented in this section, I have not found a decent way to list all recognized keys here. Quite possibly the cleanest solution would be to list all recognized keys in the description.

@return

This tag is used to document that return value of the function. It uses the same format as the @param tag: Value 1 = data type & Value 2 = description of the data. Not every function returns a value though and in cases like this I will set the data type to void. Sometimes I will use the “data description” section to document what the function does, but often I omit this if it is sufficiently explained in the description.

The last section that I always add includes the @since and @alter tags that I covered above as well as a new one: @access. If a function should not be directly used in the theme, I tag it as “private”. In cases where the user is free to place a function in a template file, I tag it as “public”.

And optional section for @todo can be added on the function level as well.

Naming Conventions

As you may already know, it is very important to create a unique prefix for all of your functions. This should be simple and unique. My theme is named “Ghostbird” so I used the prefix “ghostbird” at the start of all of my functions. I also started to adopt a naming convention that I picked up by reading core. WordPress has many “private” functions. While I don’t know the reason why each individual is marked as private, I do know that I shouldn’t really use them in my extensions. Most of these functions start with an underscore.

I think that this is a great idea! So I wanted to use it to. Looking over all of the custom functions that I created for my theme, I noticed that there were 3 specific types of functions existed:

1. Template Tags
2. Hooks (action and filter callbacks).
3. Callbacks passed to core-defined template tags.

I decided that Template Tags would be labeled as public meaning that these functions are free to be used in template files. Tagging a function as public also meant that the function could never be removed from the theme.

Hooked Functions would definitely be tagged as private meaning that they should never ever be used anywhere. If end users follow instructions and do not use these functions, then they can easily be deleted in future releases.

Callbacks are rather interesting as they embody properties of the previous two types. They need to be used directly in template files, but never alone. Functions of this type have been specifically designed to be passed to a core-defined template tag. I originally made the mistake of tagging functions of this type as “private” I now feel like they would better be tagged as “public”.

In Conclusion

While I do not use all of the tags supported by phpDoc, I have found that ones listed here are absolutely indispensable to provide useful documentation. This article represents my personal opinion and should be treated as such. I think that documentation is an integral part of any project and am always happy to see in when looking over source files. That being said, I do not feel comfortable defining rules for others to follow. Basically, I would prefer documentation in any form over no documentation at all.

Please let me know any thoughts in the comments section!

This was a suggestion of WordPress Theme Review Team member Chip Bennett as an alternative to just chopping the images short by setting the container’s overflow property to auto.

This is something that I would never have thought to do in IE6. Why? Well, while the image gets resized, it looks completely horrible Ever resize a .jpg without bicubic resampling? This is the result of scaling an image via css in IE6. See CSS Tricks for a few screen captures from different browsers.

Here’s the code that should cause an image to scale proportionally in my content area:

.entry img {
    max-width:615px
    height:auto;
}

Simple enough. If the image is greater than 615 pixels wide, set the width to 615 and the height will automatically adjust. Works in Gecko, works in Webkit … IE8? No dice! Well, until you put it into compatibility mode. Somehow. IE8 will get this right only if it is set to behave like IE7.

I scoured the internet for solutions. I even made it into page three of Google search results! I came across a similar issue in a forum and one of the answers given was to write javascript the would delete the width and height attributes from all image tags. Unfortunately, there was no code example so I came up with the following solution:

var imgs, i, w;
var imgs = document.getElementsByTagName( 'img' );
for( i = 0; i < imgs.length; i++ ) {
	w = imgs[i].getAttribute( 'width' );
	if ( 615 < w ) {
		imgs[i].removeAttribute( 'width' );
		imgs[i].removeAttribute( 'height' );
	}
}

I put this code in my theme’s footer.php file and I was sure to tell it only to fire in IE8 with conditional tags:

<![endif]--><!--[if IE 8]>

What do you think?

Have you faced this issue before? If so, did you handle it differently? Please share your solutions in the comments section.

Here’s a link to the latest development release:

Ghostbird Development Version

I would really appreciate comments on anything and everything that think about it. If you absolutely hate something, please let me know :) If I have done something horribly wrong, don’t just laugh at me, leave a comment below or on Github so that it can be addressed.

Here are a couple of sections of interest:

Post Formats

I’ve added support for all post formats except for links and would like to know your thoughts on how they are treated. A few notes:

1. Image formats have a custom filter which will allow you to enter only the url of an image. This should only work in case where the post_content contains only a url to an image.
2. Chat formats work best if you enclose the transcript inside a pre tag. This is the only way to trigger the custom filter.
3. Quote formats require the quote portion of the post to be wrapped in a blockqoute element.
4. Audio formats have no special styling. Outside of adding an icon (which I do not want to do) there is not much that I can really find to do with this format. The first thing that comes to mind is to find the first link/url to an audio file in the post_content and swap it with a fancy flash audio player. IMO this is best done through a 3rd party plugin and this is what I will suggest in the documentation.
5. Titles – All formats can optionally display a title. If an author desires no title for a formatted post, they can leave the “title” section of the post blank.

In hindsight adding support for all post formats seemed to be a bad idea. While it was fun to write some custom code to tweek their display, the over-all design of this theme does not support all post formats as I would like. While I’m nearing the end of development of Ghostbird it’s seemed like I only had two options:

1. Change the entire visual to accommodate.
2. Drop the post formats that don’t fit.

I decided to take the second route. I really like the visual aspect of the theme and, in my opinion, that’s more important than supporting all of the available post formats. It made sense to me to only support the post formats which looked and worked the best in the theme. Here’s the new list of supported formats:

1. Aside
2. Gallery
3. Status
4. Standard

Custom Taxonomies and Post Types

Support for custom post_types and taxonomies have been added directly into the theme. These elements should display well throughout the theme whether being referenced in metadata or displayed as archives. If you have an installation with custom post_types or taxonomies already defined it would be interesting to know you thoughts on how Ghostbird handles your data.

Widgetized Areas

Ghostbird currently has 4 widgetized areas. One that gets prepended to the the textarea in the contact form and 3 that display at the bottom of the #page div in a div with an id attribute of “widgets”. The bottom three work a bit differently than you might expect:

• If there are no widgets in any of the areas, no html should be printed for the the #widgets div.
• If only one area has widgets, each widget should fill the horizontal area available. The only exception here is the calendar widget which should always be ~14em wide.
• If two areas have widgets assigned then the left-most area will have a width of ~66% of the available horizontal space. The remaining 33% will be used for the second widgetized area.
• In cases where all three areas have widgets, each area should be approximately 33% of the available horizontal space.
• Although the widgets are numbered, the numbers to not define their position rather their order. If only areas 2 and 3 have widgets, they be be displayed in positions 1 and 2 in the html. Likewise if only area 3 has widgets, it will be seen as being in position #1 in the markup.

I would really like to know your thoughts on this process. Do you see it breaking any custom widgets that you use?

Intentionally Excluded

1. SEO Stuff – Ghostbird contains no seo tools whatsoever. It is my opinion that this functionality is best provided via plugin and really does not belong in a theme. Ghostbird has been tested with Yoast’s WordPress SEO Plugin. Users are suggested to use this if they want full control over their SEO.
2. Social Media Stuff – Ghostbird provides no built in method of interacting with social networks. There are plenty of plugins and users are urged to find an appropriate one for that meets their individual goals.

Did I miss anything?

If you feel limited by the functionality of the Ghostbird theme, please sound off. I actually found myself deleting functions left and right the other day in hopes of simplifying the theme as much as possible. I also moved as much html as possible from the functions files into the template files which will hopefully aid in customizing the theme. I’m sure I probably overlooked a few things. Please let me know.

Other than that, Ghostbird should work just like any WordPress theme. There is a todo list in functions.php of things that I need to deal with. I would love it if you could download the theme and test with your own custom data. I feel like I’ve designed this thing about 5 or 6 separate times in the past month. This being said there might be code fragments here and there which make absolutely no sense at all.

Things I plan on doing before release

1. Style global tables.
2. Revisit post formats.
3. Document everything in the Functions subpackage.
4. Test “big” tag across browsers – not sure about positioning here :)
5. Completely test and rewrite all examples in docs or remove if feeling lazy ;)
6. Excerpt filters for [...]
7. HTML validataion.
8. CSS validataion FWIW.
9. Add meta to search archives intro box.
10. Update and test style-editor.
11. Lighter fonts in Widgets.
12. Add Ghostbird settings page link to menu bar.
13. Style all features of the Syntax Highlighter plugin.
14. Add credit link in the footer. Credit links are lame.
15. Add donation link in the settings page. Settings pages are lame.
16. Pretty-up the calendar widget.
17. Alpha for yellow-dots.png. Change name to halftone-small.png.
18. Ensure that all settings actually do something.
19. Less saturation on #author-box bg color.
20. Make dialog colors match new theme colors.

In Closing

Version 0.9 is far from perfect and should not be used on live sites currently. I’m using it on mine and you can too, just don’t blame me if if the sun falls out of the sky :)

Thanks for reading!

I’m just about finished and was wondering if anyone would want to help me out by letting me know the #1 thing that you have found frustrating when using free WordPress themes. Here’s mine:

Lack of a unique titles across all views including custom post types, taxonomies and dated archive pages.

Just trying to cover as many bases as possible before I unleash this beast. Please leave a comment and let me know what NOT to do in my theme.

Thanks!

function mfields_add_more_to_post_class( $classes ) {
	global $post;
	if ( ( is_archive() || is_home() ) && false !== strpos( $post->post_content, '<!--more-->' ) && ! in_array( 'more', $classes ) ) {
		$classes[] = 'more';
	}
	return $classes;
}
add_filter( 'post_class', 'mfields_add_more_to_post_class' );

The Image Post Format

The WordPress Codex suggests that an image format is:

A single image. The first <img > tag in the post should be considered the image. Alternatively, if the post consists only of a URL, that will be the image URL and the title of the post (post_title) will be the title attribute for the image.

This is pretty straight forward, and I was intrigued by the possibility of using the content to hold only a url to an image. If you could just copy and paste the url to an image into the post content, it would really speed up the workflow.

I won’t go into too many details but will say that this has passed all of my tests. If you’ve got a minute to test it out, please let me know your thoughts!

<?php
/*
 * Filter content for posts having an image format.
 *
 * This filter will allow authors to post only a url to an image
 * in the post content and have the image display properly in the
 * theme as an img tag.
 *
 * An "alt" attribute will always be generated for each image. An
 * author can specify the value of the alt attribute by creating
 * a custom field with a key of "mfields_alt". If no custom field
 * is available, an empty string will be used.
 *
 * The title attribute of the img tag will be populated by the value
 * produced by get_the_title(). In the event that there is no post
 * title available no title attribute will be printed.
 *
 * Child themes may customize the attributes generated for each image
 * by registering a custom function for the
 * 'mfields-image-format-attributes' filter. An example follows:
 *
 * This filter will add a class of "mysite" to all images hosted at
 * the same domain as WordPress is installed on.
 *
 * <code>
 * function mytheme_filter_image_format_attributes( $atts, $src ) {
 *     if ( false !== strstr( $src, site_url( '', 'http' ) ) ) {
 *         if ( isset( $atts['class'] ) ) {
 *             $atts['class'] = (array) $atts['class'];
 *         }
 *         $atts['class'][] = 'mysite';
 *     }
 *     return $atts;
 * }
 * add_filter( 'mfields-image-format-attributes', 'mytheme_filter_image_format_attributes', 10, 2 );
 * </code>
 *
 * @param     string    Post content.
 * @return    string    HTML img tag if all conditions are met, unfiltered content otherwise.
 *
 * @since     1.0
 */
function mfields_filter_content_for_image_format( $content ) {
	if ( 'image' == get_post_format() ) {
		$src = esc_url( $content );
		$gis = @getimagesize( $src );
		if ( ! empty( $src ) && is_array( $gis ) ) {
			$attributes = array();
			$post_id = get_the_ID();
			$title = get_the_title();
			$defaults = array(
				'alt'    => get_post_meta( $post_id, 'mfields_alt', true ),
				'width'  => $gis[0],
				'height' => $gis[1]
				);
			if ( ! empty( $title ) ) {
				$defaults['title'] = $title;
			}
			$filtered = apply_filters( 'mfields-image-format-attributes', $defaults, $src, $gis );
			$atts = array_merge( $defaults, $filtered );
			foreach( $atts as $name => $value ) {
				if ( in_array( $name, array( 'id', 'class', 'alt', 'title', 'height', 'width', 'longdesc', 'style' ) ) ) {
					if ( 'class' == $name && is_array( $value ) ) {
						$value = implode( ' ', $value );
					}
					$attributes[] = $name . '="' . esc_attr( $value ) . '"';
				}
			}
			$content = '<img src="' . $src . '" ' . implode( ' ', $attributes ) . '>';
		}
	}
	return $content;
}
add_filter( 'the_content', 'mfields_filter_content_for_image_format', 0 );
?>