With the release of WordPress 3.0, I thought it was fair time I actually posted my long-awaited WordCamp Vancouver recap. So I am.
Justin Carlson has posted the 45-minute video of Tris Hussey and I speaking on WordPress 3.0 and child themes–check it out and listen to me nasally “um” and “uh” my way through the audience’s questions!
Finally, our presentation slides make sense!
Both during and after our presentation, I fielded a few questions, most of which were variations on a theme. I’d like to go over those now.
WordPress 3.0 and Child Themes: Frequently Asked Questions
1. When should I upgrade to WordPress 3.0?
Right now. It’s ready, it works, and updating WordPress is (usually) very easy. Keeping your WordPress and plugins current is the best defense against having your site hacked. (Assuming your password is not ‘password’ or ‘secret’, that is. If it is, go change it right now.)
2. When should I use a child theme?
All the time. If you want to modify your site’s look and feel beyond changing the background image on Twenty Ten, you need a child theme.
3. Why? That sounds crazy. Don’t you emphasize in your presentation that my current theme will still work exactly the same way?
Sure, and I’m a big proponent of doing as little work as possible while staying current. Yes, the WordPress 1.x theme you’ve been using since 2004 will still work on WP 3.0. Yes, the functionality will remain the same. However, if basing a new theme on an existing one, establishing it as a child both reduces the amount of code you need to change while keeping it separate and independent of the parent.
If you build themes from scratch–say, like me, for example–it’s far better to work from the same initial structure, rather than trying to reinvent the wheel every time. In the past, that might have involved copying the same code over to a new theme and working from there.
With child themes, I can set the background, column width, colours and typography for a new site with fewer than a dozen declarations, isolating only the changes relevant to that site in a separate CSS file. The key benefit of this becomes apparent when performing updates. Suppose I add a new feature to my child theme’s functions.php, or find a cleaner way to format dates in style.css. I can then copy those changes back to the parent theme, allowing me to very quickly add that functionality to existing sites without having to touch their respective child themes.
4. But when would that ever happen? Seriously, isn’t that kind of an edge case?
WordPress 3.0 adds extraordinary new levels of control over author templates, giving us the ability to style individual authors’ profiles for the first time. Future versions of WordPress may contain similar features to allow us to more flexibly aggregate lists of users, a greater range of default fields, and so on. By limiting the changes necessary to your own theme to accommodate these hypothetical future additions to WordPress, you can be assured that your site will gain features as your parent theme is updated, rather than being locked into static functionality long after future versions of WordPress give you blogging and styling features we can only dream about today.
5. Custom content types: should I be using those?
Consider the following scenario: You have a bunch of posts. Some of those posts are reviews. Reviews can quickly fall out of date, so they need updates. These updates should be very clear to users, allowing them to quickly see how old–and therefore relevant–a review is. So, what to do?
Option A: We need types. Lots of types.
Create a custom post type called “Reviews” and one named “Review Updates”, that in turn, can be associated with the Reviews type. Both can be easily themed differently than your standard Post and Page types.
Option B: Custom Fields
Create your “Reviews” type, but add custom fields to it, allowing for those updates right in the post itself. That might be cleaner, though it would be tougher to add features to your blog like a “Recent Updates” sidebar widget, if that’s something you’d like–now or in future.
Option C: Just leave it alone.
Alternatively, you could just add “Update, June 25th, 2010″ to the bottom of the post, surrounding it with a DIV, allowing you to style “updates” accordingly. You’d have much less work ahead of you, and you wouldn’t run into problems with your custom post type not fitting the content.
This latter method is actually what I’m doing on this very site with my new feature, Catherine Uses…. It’s just easier for me to copy and paste a little code, adapting it as necessary.
As I’ve written before, plain text will always be more flexible — at least, if you’re the only one editing your blog. If this custom post type would be used by a dozen different writers, it can make more sense to standardize rather than train everyone on adding DIV tags to all their updates.
6. When should I use Multisite?
This is actually a fairly complicated answer for a number of reasons.
Short answer: you shouldn’t. If there’s a choice between using multisite and not, my recommendation is that you don’t. If you have no choice, IE, you’re running dozens of WordPress blogs on the same server, well, at least WordPress and WordPress MU have the same codebase now.
Got another question on WordPress 3.0 or parent/child themes? Feel free to ask in the comments!