I actually doubt Dan Benjamin¹ uses WordPress or cares about custom fields. The point is, your average client shouldn’t have to know or care about custom fields. I’d be happy if they were disabled by default — as long as I have an option to enable them by defining a constant in the wp-config file.

With a bit more work on your end as a developer, you can create a custom meta box that points directly at a custom field. If you’re really crazy about it like I am, you could even use a hidden key for you custom field by starting the name of the key with and underscore.

I think the ideal situation is if you happen to be working with a custom post type. It’s easy enough to turn custom fields on or off for any post type you create. So you can do all your testing with the custom fields turned on and turn them off when you get everything set and ship the theme off to the client. In the scenario, I don’t even bother using hidden keys, since there’s no way to access them directly through the custom field boxes anyway.

Advantages

There are a few advantages to doing things this way. The most obvious is that the client sees a nice clean interface with inputs that can be customized, explained, and show on every edit screen. You don’t have to teach anybody about adding custom fields or any of that. It’s just another box you can type stuff into.

The second major advantage that I see is that it doesn’t just have to be an input box. On a recent project I used a checkbox because it was an on/off thing and saved it directly to a custom field. I suppose it’s easy enough to explain to somebody that they have to type “1″, or “true”, or “Fdsfjje4jjfdsa9F#(d8df” into the custom field box; but if I can make something dead simple to use, I feel like it’s usually worth it in the long run.

So custom fields are fine for me, or you, or maybe Dan Benjamin, but don’t make your clients learn what they are. It can be, and should be, easier than that.