Need a WordPress website this weekend? Start here...

Get some face time: WordPress 3.1 @ Techliminal Oakland

(Reading time: 3 – 5 minutes)

I’m hanging out in Oakland at the moment, at Techliminal, a coworking space on 14th Street owned and operated by Anca Mosoiu. Contrary popular belief, there are “theres” there, and Techliminal certainly is one of the theres.

Regardless of your opinion of what constitutes here or there, at the time I’m writing these words, I’m sitting in Techliminal’s downstairs meeting area. The occasion is yet another excellent East Bay WordPress Meetup, where Sallie Goetsch (rhymeswithsketch) is discussing the upcoming release of WordPress 3.1.

Woops. There’s the pizza… Back in a bit… Scrumptious. Six humongous pizzas pies from Oakland Pizza Man provided by Ann Zerega Design.

Back to work…

“Hi, my name is…

There are about 35 people here, we’re doing introductions, around the room we go… seems we have about half designers of some sort, another slightly more than quarter are beginner bloggers, and a final slightly less than quarter are interested in starting a blog, or using WordPress for a website.

Introducing WordPress 3.1, featuring…

First, take a look at the WordPress 3.1 Codex page. Clear as mud, right? Investigating all that takes some serious time, especially since so much of it is under the hood.

But what if someone installed an early release of WordPress 3.1 and showed you all the important stuff?

Well, that’s what Sallie did. Now you can check out these notes I took during her presentation, from the comfort of your own living room:

  1. Sortable post listing: Fresh Ajax, column heads on posts allow search by post attribute. This is super handy for me, I will be able to sort by author.
  2. Post edit screen customizable via screen options: this one isn’t rocket science, but it’s still useful, especially when managing clients who need as little access as possible to “the controls.” I suspect it’s one of those features which has been lurking in the system as “nice to have” for years.
  3. Aside post type: This should probably be called a Ma.tt, because that’s how Ma.tt likes to blog. So check it: an Aside has no title and no permalink. How this benefits anybody, I can’t really say right now. Lemme get back with you on that one.
  4. Gallery post type: This will be super duper for people who post photo galleries. I do not. Next!
  5. Internal linking support: I’m a big of internal linking, and not just for SEO support. Done well, it helps readers follow the narrative arc of your blog. You do have a narrative arc, right? Tell me you have at least thought about building your blog around a narrative arc…
  6. Sortable comments: this rocks! I don’t tend to search comments because it’s so difficult. But I could if I would. I like linking to directly to comments, and I’ll do more of it when I can easily find the comment I want to link to.

My notes aren’t complete; I cherry picked what was most interesting to me. You can see slides clicking through the link given below.

Recapping…

And questions for you: have you had a chance to check out the new features? If not, what are you looking forward to the most?

3 Fast Techniques for Thesis Theme custom_functions.php

(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.