In this example, we’re going to look at the popular k2 theme and see what it takes to consolidate their settings into one single database entry.

Upon installation, k2 runs an install function that adds several settings into the database.

function install() {
	add_option( 'k2version', K2_CURRENT );
	add_option( 'k2asidescategory', '0' );
	add_option( 'k2livesearch', '1' );
	add_option( 'k2rollingarchives', '1' );
	add_option( 'k2archives', '0' );
	add_option( 'k2sidebarmanager', '0' );
	add_option( 'k2columns', '2' );

	// Added 1.0-RC8
	add_option( 'k2animations', '1' );
	add_option( 'k2entrymeta1', __('Published on %date% in %categories%. %comments% %tags%', 'k2_domain') );
	add_option( 'k2entrymeta2', '' );
	add_option( 'k2widgetoptions', array() );

	$defaultjs = "// Lightbox v2.03.3 - Adds new images to lightbox\nif (typeof myLightbox != 'undefined' && myLightbox instanceof Lightbox && myLightbox.updateImageList) {\n\tmyLightbox.updateImageList();\n}\n";
	add_option( 'k2ajaxdonejs', $defaultjs );
}

We’re going to recreate that install function, but first, lets add a new function that stores the default values for each option as an array:

function k2_default_options() {
	$defaultjs = "// Lightbox v2.03.3 - Adds new images to lightbox\nif (typeof myLightbox != 'undefined' && myLightbox instanceof Lightbox && myLightbox.updateImageList) {\n\tmyLightbox.updateImageList();\n}\n";
	$options = array(
		'version' => K2_CURRENT,
		'asidescategory' => false,
		'livesearch' => true,
		'rollingarchives' => true,
		'archives' => false,
		'sidebarmanager' => false,
		'archives' => false,
		'columns' => '2',
		'animations' => true,
		'entrymeta1' => __('Published on %date% in %categories%. %comments% %tags%', 'k2_domain'),
		'entrymeta2' => '',
		'widgetoptions' => array(),
		'ajaxdonejs' => $defaultjs,
	);
	return $options;
}

You’ll noticed that I removed all prefixes of k2 as their not needed when everything is being stored under one entry. I also converted all the 0’s and 1’s into their boolean values. Now let’s recreate the install function:

function install() {
	add_option( 'kaytwo', k2_default_options() );
}

It’s as simple as that. Retrieving those values is just as easy:

$kaytwo = get_option( 'kaytwo' );

echo $kaytwo['version'];
echo $kaytwo['columns'];
echo $kaytwo['entrymeta1'];

Updating options involves retrieving the entire options array and updating only those that need to be updated.

$kaytwo = get_option( 'kaytwo' );

$kaytwo['version'] = '1.0';
$kaytwo['columns'] = '4';
$kaytwo['entrymeta2'] = __('Posted in %categories%. Tagged: %tags%', 'k2_domain');

update_option( 'kaytwo', $kaytwo );

Remember to include all options, even those that are not being updated themselves. Failure to do so removes those options from the database completely.

Deleting an option is similar to updating. Retrieve the entire options array and unset those that need to be removed:

$kaytwo = get_option( 'kaytwo' );

unset( $kaytwo['sidebarmanager'] );
unset( $kaytwo['asidescategory'] );

update_option( 'kaytwo', $kaytwo );

And that’s how you would consolidate all your options under a single database entry. But why stop here? Since we’re going to be interfacing with the database all throughout our WordPress theme, let’s make these calls into functions.

define( 'THEMEOPTIONS', 'kaytwo' );

/**
 * Returns the value of an option from the db if it exists.
 *
 * @since 0.4
 *
 * @param string $name Option Name.
 * @return mixed Returns the option's value if it exists, false if it doesn't.
 */
function framework_get_option( $name ) {
	$options = get_option( THEMEOPTIONS );
	if ( isset($options[$name]) ) {
		return $options[$name];
	} else {
		return false;
	}
}

/**
 * Adds an option to the options db.
 *
 * @since 0.4
 *
 * @param string $name Option Name. Must be unique.
 * @param mixed $value Option Value.
 * @return bool True on success, false if the option already exists.
 */
function framework_add_option( $name, $value ) {
	$options = get_option( THEMEOPTIONS );
	if ( $options and !isset($options[$name]) ) {
		$options[$name] = $value;
		return update_option( THEMEOPTIONS, $options );
	} else {
		return false;
	}
}

/**
 * Updates an option to the options db.
 *
 * @since 0.4
 *
 * @param string $name Option Name. Must be unique.
 * @param mixed $value Option Value.
 * @return bool true|false
 */
function framework_update_option( $name, $value ) {
	$options = get_option( THEMEOPTIONS );
	if ( $value != $options[$name] ) {
		$options[$name] = $value;
		return update_option( THEMEOPTIONS, $options );
	} else {
		return false;
	}
}

/**
 * Deletes an option from the options db.
 *
 * @since 0.4
 *
 * @param string $name Option Name. Must be unique.
 * @return bool true|false
 */
function framework_delete_option( $name ) {
	$options = get_option( THEMEOPTIONS );
	if ( $options[$name] ) {
		unset( $options[$name] );
		return update_option( THEMEOPTIONS, $options );
	} else {
		return false;
	}
}

Just define THEMEOPTIONS as the name of the database entry and your all set.

To read more on this topic, check out this post on Striderweb.

Let’s talk about what we can do now. WordPress allows you to create action hooks at any point in your WordPress theme to allow other functions to be executed at that particular location. Well that’s pretty cool. But what about context? If you’ve ever used any sandbox-based theme, you should be familiar with the class generating functions it pours into the body tag and other sections throughout your theme. Those functions give CSS clear context as to what page is being displayed and a lot more specifics.

So if we had a #header div that displayed our site’s name and tagline, those class generating functions would allow us to style the #header div differently for pages, archives, or any other template without adding any if, else logic to the actual template file.

<!--BEGIN #header-->
<div id="header">
	<h1 id="logo"><a href="<?php bloginfo( 'url' ); ?>"><?php bloginfo( 'name' ) ?></a></h1>
	<p id="tagline"><?php bloginfo( 'description' ) ?></p>
<!--END #header-->
</div>

#header { background-image: url( '../images/header.jpg' ); }
.page #header { background-image: url( '../images/header-page.jpg' ); }
.single #header { background-image: url( '../images/header-single.jpg' ); }

So that got me thinking, why not do this for action hooks too?

Chris Jean wrote an improved version of the get_context() function which you should definitely check out.

/**
 * Retrive the context of the queried template.
 *
 * @since 0.4
 * @return array $context
 */
function get_context() {
	global $wp_query;

	$context = array();
	$id = $wp_query->get_queried_object_id();

	// Absract context
	is_singular() ? $context['abstract'] = 'singular' : null;
	is_archive() ? $context['abstract'] = 'archive' : null;

	// General context
	is_front_page()	? $context['general'] = 'home'      : null;
	is_page() ? $context['general'] = 'page' : null;
	is_single() ? $context['general'] = 'single' : null;
	is_search() ? $context['general'] = 'search' : null;
	is_attachment() ? $context['general'] = 'attachment' : null;
	is_author() ? $context['general'] = 'author': null;
	is_category() ? $context['general'] = 'category' : null;
	is_tag() ? $context['general'] = 'tag' : null;
	is_tax() ? $context['general'] = 'tax' : null;
	is_404() ? $context['general'] = 'error404' : null;
	is_date() ? $context['general'] = 'date' : null;

	// Specific context
	is_page() ? $context['specific'] = 'page-'. $id : null;
	is_single() ? $context['specific'] = 'single-'. $id : null;
	is_attachment() ? $context['specific'] = 'attachment-'. $id : null;
	is_author() ? $context['specific'] = 'author-'. $id : null;
	is_category() ? $context['specific'] = 'category-'. $id : null;
	is_tag() ? $context['specific'] = 'tag-'. $id : null;
	is_tax() ? $context['specific'] = 'tax-'. $id : null;
	is_month() ? $context['specific'] = 'month-'. $id : null;
	is_year() ? $context['specific'] = 'year-'. $id : null;
	is_day() ? $context['specific'] = 'day-'. $id : null;

	return $context;
}

get_context() returns an array containing the context of the current queried template. The context is broken up into three tiers, abstract, general, and specific.

Now, that we have some context, let’s put it into action. Here’s the new and revised do_atomic() function:

function do_atomic( $location = '' ) {
	$context = get_context();
	$prefix = apply_filters( 'do_atomic_prefix', 'theme_hook_' );

	// Global context
	do_action( $prefix . $location );

	// Abstract context
	if ($context['absract'])
		do_action( $prefix . "{$context['abstract']}_{$location}" );

	// General context
	if ($context['general'])
		do_action( $prefix . "{$context['general']}_{$location}" );

	// Specific context
	if ($context['specific'])
		do_action( $prefix . "{$context['specific']}_{$location}" );
}

So now using do_atomic(), we can treat our action hooks just like we always did. In addition, do_atomic() registers up to 22 different contexts, so if you’d like to display something specific to page templates or archives-based templates, do_atomic() allows you to do so without creating any additional code.

Let’s go back to our header.php and replace the #header div with this:

<?php do_atomic( 'header' ); ?>

And now, viewing a page template, you’ll have four actions fired in this order:

1. theme_hook_header
2. theme_hook_singular_header
3. theme_hook_page_header
4. theme_hook_page-id-5-header

This way, you can specify a variety of looks for the header (albeit, it’ll probably be more than just a small trivial change) all while keeping your template files clean and clutter free of if, else and is_* statements.

theme_before_location();
theme_location();
theme_after_location();

Where location is the location of that particular hook (e.g. header, footer, loop). Now that’s great and all, but here’s a smarter way:

do_atomic( 'location' );

Where do_atomic is:

// Registers three action hooks at once.
function do_atomic( $location = '' ) {
	if ( !isset($location) ) return;

	do_action( "theme_before_{$location}" );
	do_action( "theme_{$location}" );
	do_action( "theme_after_{$location}" );
}

Makes for much cleaner template files. The next article on smarter hooks will take this concept to an even higher level.

On the same path… If you have a child theme (I’ll use Ian Stewart’s pro/paid Thematic child theme called Power Blog, as the example) and want to customize that – what do you do? Currently we’re talking about customizing themes by using Child Themes. If I wanted to make mods to Power Blog, I’d have to change the child theme directly, thus negating some of the reasons for using a Child theme – like upgradability.

Do we get to a day where we need grandchildren themes? I think your code might be the start of a way to “group” the family theme files together. -Kel

The day WordPress starts talking about “grandchild” themes is the same day I’ll convert all my blogs over to movable type Habari.

Way back when I started talking about theme frameworks, I talked about how WP Framework stands out:

One of the main design goals I wanted to achieve with WP Framework that differentiates it from other frameworks is the fact that it’s not styled.

A WordPress theme framework should be design-agnostic. That’s why it’s a framework. It should only contain the building blocks and the most essential code (by the way, WP Framework 0.2.4 has just be released!).

Carrington gets it. Alex King built a base framework of carrington, basically extracted all the template logic and things that made his theme work into a “core” framework. When he builds themes off of carrington, he simply extends the core framework by building on top of it; not via a child theme.

So if users of Carrington blog wanted to customize it, they would create a child theme for it and modify it accordingly. Here’s two possible scenario’s that show the benefits of what I’m describing:

• Carrington blog gets an update that includes a new section above the sidebar (a feature dealing with the design, not the logic). Users would simply download/update Carrington blog and the new section would appear above the sidebar as expected. All of the user’s changes for Carrington is preserved and left intact via the child theme.
• But let’s say Carrington framework fixes a bug in it’s atomic template system (an issue dealing with the framework logic, not the design). There would be an update available to all themes based on carrington, and users would simply download/update carrington blog (or which ever theme based on Carrington they have) and the fix gets applied. The user’s modifications to Carrington blog are left intact via the child theme.

It’s important to think of a theme framework as the logic of the theme, not the design or the underlying xHTML.

To put this into a step by step process:

1. Start with a blank WordPress theme framework
2. Create your WordPress theme based off said framework
3. Now to customize this WordPress theme (which is essentially the first two steps combined), create a child theme for it.

That’s how WordPress theme frameworks should work. In Kel’s case, Thematic already consist of the first two steps described above when it should only be the first one. So now that she’s using the Thematic Power Blog, she won’t be able to customize her theme using a child theme because it’s already one.

function has_kids() {
	if (STYLESHEETPATH !== TEMPLATEPATH) return true;
	return false;
}

if ( has_kids() ) {
	// do stuff
}

This function works whether you call it from a child theme or parent.

Unlike all the other CSS Frameworks out there, this framework allows you to define your own columns, widths, and gutters (margins). Thus, rollyourown.gs was born.

It’s simple, and it works. Once I get enough time for it, I’ll give it a proper face and add some more features to it. Until then, have fun with it.

#8
WordPress plugins can sometimes be a real resource hog. To make sure your plugin isn’t, you need to localize the usage of resources, by loading them only when you need them.

You can use the following example to execute certain code (like declare additional actions and filters) only when WordPress is loading plugins.php page (list of installed plugins in the backend):

$local_pages=array(’plugins.php’); // define pages we want the plugin to be activated on

if (in_array($pagenow, $local_pages))
{
// do stuff here
}

Similar to this, you should pay attention to load JavaScript files only when you need them.

All too often I find plugins, like contact forms being loaded on every single page. It’s not that hard to figure out where the user likes to put their contact form, or whatever your plugin does. And while these tips were geared for plugin developers, theme authors should take this advice too as theming becomes more advance and not just an new stylesheet addition.

I’m looking forward to hearing more things like this on the next WP Weekly episode where Jeff interviews him.

Before I get ahead of myself, I’m pretty sure you’re wondering what exactly is Design by Craftsmen? Well in a nutshell, DBC is a web creative studio specializing in custom WordPress solutions. I examine the way a company currently does business and use the Web to make their work flow and process more innovative, intuitive and efficient, using the power of WordPress and WP Framework.

Currently, Design by Craftsmen has been working with entrepreneurs, startups and small businesses locally and several nationally, but once the website is up, the target audience will expand internationally. More on the DBC website in another post perhaps.

One of the goals I’ve been working on for DBC is improving my work flow on dealing with clients. Here’s a typical workflow outlining the process involved for creating a website:

1. Client needs website
2. DBC sends them a questionnaire document so they can get their ideas onto paper
3. Either 1) Client fills out questionnaire and sends it back or 2) We have a meeting and fill it out for them (still debating on this route)
4. Either 1) DBC evaluates the questionnaire to see if we can deliver a solution for them or 2) If not, we’ll see if we can forward them to one of our partners.
5. If we can provide the client a solution, DBC sends the client a creative brief document containing all the project details.
6. If client agrees to pursue this project with us, they’ll sign off on the creative brief + a TOS document. DBC will then invoice the client the initial deposit in order to start the work.
7. Once that’s completed, the client will gain access to DBC’s project management app to collaborate, and see the development throughout the life cycle for that particular project.
8. DBC then starts working on the first deliverables of the project.
9. This part varies depending on the type of project. But overall, we’ll be communicating back and forth showing revisions etc.
10. Once half the deliverables have been completed (this milestone will be known to the client), DBC will invoice the client before the second phase starts.
11. Step 8 through 9 will repeat but for the second phase of the project. And so forth.
12. Once DBC is completed with the final phase and the client approves of the work, DBC sends them the last invoice and the deliverables  are given to the client.
13. The project is completed.
14. Follow up

Now that’s just a rough overview of our workflow. Things will changed depending on the type of project/client/situation but it’s a solid workflow that I’ve been perfecting over the years and it has a pretty high success rate. Working like this also ties well into the agile workflow which is something I’ve been growing into.

As you can see, there are about three documents that DBC has going into each project.

1. Questionnaire
   The purpose of this document is to get all their project details onto paper so we can figure out what their looking for and evaluate if that’s something we do. If so, we’ll figure out how it’s going to work along with an estimate quote (the Creative Brief doc). If we can’t do it, we’ll send them to one of our partners if they can best fill the roll.
2. Creative Brief
   This document outlines all the deliverables for the project, project goals and itemizes our services so they know what their paying for. The creative brief is sort of the reference, goto document that DBC or the client can refer to if something’s not clear, or if things get a little blurry down the line.
3. Terms of Service
   Finally, the TOS. This document simply contains all the legal jargon to project DBC’s assets, if you know what I mean. That’s all really.

Financing

As you saw throughout the client to DBC workflow, we allow the client to make payments overtime. For the most part, it’s typically a three step: 50%, 25%, 25% payment. I’ve found that this works best for both parties.

Services

So in terms of services, here are some of the standard services we provide:

• Design to HTML conversion
• Design or HTML to WordPress
• Custom WordPress Theme development
• Custom WordPress Plugin development
• Basic small website (static)
• Large website (not the proper name, but this is what the client needs 40% of the time)
• Website redesign
• Small custom web application
• E-Commerce website

That’s roughly what we do. Other services like logo design, copywriting, hosting and site maintenance are also what DBC provides, but are already included in some packages. Part of the initial work I had to done last month was to figure out all of the base prices for these services. That process involved creating a sample project 3 times for each service, and timing myself to get a good estimate on how long it takes.

Partners

If you were reading carefully, I keep referring to DBC as  “we” and “our” throughout this post. That’s because I’ve partnered with two amazingly talented folks, Maricio Bowers, a web designer here in Atlanta and Evan Denbaum, an amazing copywriter based in California. So that makes DBC 3 strong. I’m looking to build this team to include another web designer. So if your a designer looking for work, contact me asap!

Partnering with DBC simply means that we’ll be able to list the services you provide (e.g. web design if your a web designer) through us. DBC will contract that type of work through to you when needed. And as an incentive you’ll be entitled to a nifty 20% discount on any of the services DBC provides if you’d like to use us. I think that’s a sweet deal.

Business Models

Apart from the services DBC already currently provides, I’ve been brainstorming a few ways we could create passive incomes to fill in the gaps when we aren’t doing client work. I’m still working out some technicalities, but we’ll be pushing something out in the coming months.

Working hours

I’ve decided that working hours are 9-5, Monday through Thursday, and 9-12 on Fridays. I wanted to try out the 4 day work week model, but that just isn’t realistic for my situation. So Fridays I’ll work just in the morning, and I’m off the rest of the day. Now the only thing I need to do is follow through with this! I tend to work around 56 hours a week on average. They say it takes about a month to develop a new habit, so hopefully I’ll have this work-life balance back on track pretty soon.

Overall, that’s where I’m at with DBC. Getting the DesignbyCraftsmen.com website up and online is one of my top priorities right now. But before hand, I need to fill it with some quality portfolio pieces. I’ve got around 4 or so in the works so things are trucking along.