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

Custom post types at San Francisco WordPress Meetup (Face time!)

(Reading time: 4 – 7 minutes)

It has been cold in the San Francisco Bay Area the last week or so… I know, I know, I can hear you out there “Cry me a river, Dave, it’s what you deserve for all those `Another beautiful day in Paradise’ tweets.”

Fine. We’re spoiled here in The City by the Bay. And we like it!

We’re spoiled in more ways than the weather here in San Fran. For example, I’m sitting here in the Automattic lounge on San Francisco’s Embarcadero listening to developer Michael Enslow present the work his company Mister Machine did for Social Media Week.

Automattic Lounge (courtesy Beau Lebens)

I don’t know Michael personally, but he’s someone I pay attention to because 1. he works with WordPress and 2. he actively develops with HTML5, an important technology you will be using very soon.

You may not know when you’re using HTML5, and that’s ok. Just expect better websites, that’s the take home.

Here’s what’s interesting about the talk:

  • The Social Media Week site was built from scratch using a stripped down, in-house WordPress theme template.
  • The theme leveraged HTML5Boilerplate and Modernizr to bring cutting edge capability to the website.
  • The advantage of using custom post type is being able to get better display of the content on the browser page.

What’s best about all this is hanging out, in person, at the San Francisco WordPress Meetup with about 75 other rabid WordPress aficionados.

Lydia Sugarman, a good friend of mine from the San Francisco entreprenuerial startup circles is here. Ralph Carlson was on his way down from the hills, but his car got cantankerous around Davis (60 miles up the road). No worries, Ralph will be down for a future Meetup. New friends Chantal and Yoli, both talented website designers, are also in the audience.

Woops, someone asked for a show of hands… about 30% of the audience has been working with custom post types and taxonomies. An invisible groundswell.

Stir in custom taxonomies

Next up is Zach Berke of Exygy.com, with details about how custom post types and taxonomies for the Skoll Foundation website.

  • Custom taxonomies are to categories as custom post types are to regular posts. This allows more dynamic feeds, as a new custom post can be associated with custom taxonomy.
  • Where you would normally see a “Category” metabox on the post editor, you can have a custom taxonomy box.
  • Using Brad Williams Custom Post Type UI Plugin for WordPress was a key piece of the implementation puzzle.

This is powerful stuff!

The key to custom taxonomy is defining the elements of the taxonomy. That is, you have to get your taxa in order, taxa being those taxon comprising your taxonomy.

Zach showed how getting this right allowed much more sensible navigation through the Skoll Foundation website. People associated with various issues and causes can be found and listed automatically.

Post formats make life easy for theme developers

Next up: Beau Lebens on Post Formats, a feature introduced in WordPress 3.1. From the Codex link:

Post Formats is a theme feature introduced with Version 3.1. A Post Format is a piece of meta information that can be used by a theme to customize its presentation of a post. The Post Formats feature provides a standardized list of formats that are available to all themes that support the feature.

Having standard post formats in WordPress Core really helps theme developers.

This is not to be confused with Custom Post Types, even though it is confusing. A custom post type is a reference to the content contained in a post, and nothing to do with how such content may be displayed. WordPress developer Mark Jaquith has an excellent article on Post Formats vs. Custom Post Types. Definitely worth reading if the difference is important to you.

Mixed media socialization

You’ve undoubtedly heard of mixed media art, maybe even seen it in real life. Certainly, if you’ve ever been to Burning Man, that’s about as mixed as media gets.

A while back, in a comment elsewhere, I described social media as getting the “social,” and not worrying overmuch about the medium. While I’m definitely not the most relentlessly social person, since I’ve started reaching out in person to people I know from online, I’ve noticed a nice carryover effect: the offline and online work together.

If you can find a WordPress or marketing or writing or some other group or meetup close by, attend!

The upshot: if you’re not out there getting some face time with your online colleagues, consider reducing some of your online time and increasing your offline time.

What’s your experience? Are you getting out there and pounding some pavement? Is it helping? Hurting? Comment below!

Saturday Morning Surfing: When a bug is unfixable; leave it alone

(Reading time: 5 – 8 minutes)

Programming is fun and easy compared to keeping track of everything.

One of the things I have to keep track of is the Thesis custom_functions.php source file for my Thesis custom template pages. This file sits on the web server of course, but also in a source code repository, and in a local copy running on my development computer.

Normally, this isn’t a problem.

Then I edited custom_functions.php through the built-in WordPress file editor. I forgot that the plugin editor strips out newline escapes ("\n""n"), which litters the web page with random letters “n” and thoroughly destroys the layout.

Now, having multiple copies is a problem, because one of the copies is broken.

So I spent a unhappy afternoon being stymied by an “unfixable bug” in the WordPress plugin editor.

“Works for me”

I’m not the only person who has had this trouble.

But none of the WordPress developers have it.

As you can see from the screen capture of the WordPress Trac ticketing system, issue #10903 is closed with a “worksforme.”

That’s a very hackerish thing to say.

I can’t say I blame them. WordPress is free software after all. If this issue really were a problem for me, I’d knuckle down and fix it myself, or pay someone to fix it for me.

Instead, I make like the internet and route around the damage.

The No-solution Solution

The no-solution solution for fixing bugs is pretty simple. Here’s a few concrete suggestions:

1. Leverage the pain of others.

Typically, when you have a bug in a piece of software like WordPress, many other people are experiencing the same problem.

Most likely, someone has also reported the problem.

Once the problem has been reported, it goes on a release schedule for eventual fixing (or not). You have little control (none) over the release schedule, so…

2. Do something else.

For me it falls into the category of “If it don’t work, find sumpin else to do.”

In my example above, I just stopped using the built-in plugin editor. I routed around the problem. Simple.

But that’s not good enough for some people. For example, Holly Jahangiri prefers a more direct approach:

That is an entirely-too-practical approach to life, David. I gravitate towards the “if it don’t work, beat your head against a brick wall until your ears bleed and some geek takes pity on you and figures it out so you’ll stop” approach. :)

3. Bang your head until your ears bleed.

A while back, Jena Isle had a problem with one of her articles submitted to Digg. The article could be loaded from her blog, but it came back with Invalid URL from Digg. It ended in my lap via Holly Jahangiri:

…”Invalid URL” has to do with special characters in the title. In this case, there are no obvious special characters, but when you try to Digg (or strangely enough, even copy from the address bar) the URL from the post page – Bam! error.

Bang your head until your ears bleed.

I did some poking around on Google, and found that it was known but infrequent problem, and nobody has any idea how to fix it. Blood, leaking from my ears… I emailed Holly something like “Don’t Digg that article.” Problem solved!

Holly, to her credit, continued to bang her head:

Oh, well, it’s still working for me – that bleeding out the ears thing – except there were no geekier geeks racing to my rescue and I did figure it out, finally, I think. For some reason, somehow, it was taking the url as having a comma before blogspot (I have no idea why, unless there’s some place to set that in the plug-in Jen’s using, but I suspect maybe, just maybe, it’s some weird error somewhere in her settings). Anyway, digging it from the FRONT page, not the post page, worked.

Yikes!

If head banging isn’t your thing (and nothing wrong with it if it is), you need to know…

When to punt

Free software such as WordPress depends on users reporting and, when possible, fixing bugs. It’s a good model, as you can see from the wild success of WordPress.

Fixing, or even reporting bugs isn’t always feasible. Putting on my developer hat, when a user can’t precisely describe a bug so that I can reproduce it, I’m not going to have time to fix it. Likewise, when I don’t have to precisely describe a bug, I won’t report it either.

Here are a few guidelines I use for deciding whether to fix or report bugs:

  • Do I have time? It’s going to be an hour’s work, at least. If fixing it won’t save me time in the long run, punt.
  • Does Google bring back junk? We’re getting close to the day when just about any keyword or phrase with traffic is going to be gamed. If I get no related results from search, punt.
  • Is the bug close to my competence level? There is this notion of a “technology stack” (which I’ll write more about in the future*). This means I’ll consider fixing bugs in WordPress, but not in the web server, etc.

NOTE: All of these guidelines apply to like activities, for example, web and WordPress theme design.

If something is just too hard to do, that’s a hint!

As a public service, here’s a recap of techniques for handling bugs:

  1. Leverage the pain of others.
  2. Do something else.
  3. Bang your head until your ears are bleeding.

Can you add to this list? What’s your special technique for handling bugs?


* BPE customers: this is a forward hook.