(Reading time: 3 – 5 minutes)

Is your custom_functions.php file bloated beyond all recognition? Do you cringe in fear every time you need to ever-so-slightly tweak your Thesis theme? Do you lay awake at night in horror of dropping a silly semi-colon?

If so, or even if not, wouldn’t it be great to protect your tweaks from rampaging hackery?

Of course it would!

You need these three simple techniques which will make your custom_functions.php file spic-and-span, reduce bugs, and promote good feelings all around. Who wouldn’t want that?

Include your way to cleanliness

See that fat footer at the bottom of Website In A Weekend? That’s Thesis custom fat footer code (credit: Mike Nichols). Since Mike’s code Just Works, I got tired of scrolling past it. So I stuck it into it’s own file. The wiaw_fat_footer.php file, as you can see below:

1
2
3
4

/// Cool stuff!
if (file_exists(THESIS_CUSTOM . '/wiaw_fat_footer.php')){
	include(THESIS_CUSTOM . '/wiaw_fat_footer.php');
}

The beauty here is staggering. I don’t need to read code. I can see what it does by looking at the bit literate file name. If the file doesn’t exist, it doesn’t try and load and crash.

Load styles only when necessary

Suppose you have, as I have, a collection of Thesis custom page templates.

With each custom page, you have a collection of styles.

You could add all of these styles at the end of your custom.css stylesheet, but it starts to get crufty if you have more than one custom page template, or your custom page is very complex (or both).

Fortunately, we can factor out the styling for each custom page, and load up our css only if we need it. Here’s what that looks like in my custom_functions.php:

1
2
3
4
5
6
7

function is_load_custom_stylesheets() {
    if (file_exists(THESIS_CUSTOM . '/inventium_front.css')) {
	   wp_register_style('inventium_front','/wp-content/themes/thesis_18/custom/inventium_front.css');
	   wp_enqueue_style('inventium_front');
    }
}
add_action('wp_print_styles', 'is_load_custom_stylesheets');

Manage your options automatically

Thesis options are handled in the Thesis lib/classes/options_*.php files, where the * stands in for “pages,” “design.” etc. Go poke around, you’ll see them.

Since digging around in the graphical front end for Thesis options annoys me at times, I use code like the following to get it handled, once and for all. In this case, I want the Multimedia box off:

1
2
3
4
5
6
7
8

function remove_multimedia_box() {
   $design_options = new thesis_design_options;
   $design_options->get_options();
   // Turn it off!
   $design_options->multimedia_box['status'] = 0;         
   update_option('thesis_design_options', $design_options);         
}         
remove_multimedia_box();

Easy peasy, slightly greasy…

This cleanliness comes at a minor price: disk reads, which are expensive.

But… but but but…

If you’re smart and using a caching plugin, you probably won’t notice the overhead.

Also, consider that WordPress already loads up a hundred or more files, and plugins load up anywhere from another one to 100 files (each), so loading a few more in custom_functions.php really isn’t going to matter very much.

That’s the downside. Let’s recap the benefits:

1. Keeping your custom_functions.php file short with include statements makes it easier to debug. If an included file is broken, stop including it. Easy.
2. You can distribute your included files (and css) as a package. Almost like a Thesis mini-plugin. Anyone else can use it by adding two lines of code. That’s cool.
3. Handling options directly saves a lot of time fiddling around with the graphical interface for Thesis options. Sometimes, having a graphical interface is good. Other times, not so much. Now, you get to choose how you want to deal with options.

That’s all from me today. How about your custom tricks? Got anything to share? Comments below.