The handling of plugins in WordPress 2.5 is perfect. It’s superb. It’s easy. It’s cake. But now that I have cake, you know, I want to eat it too. I’ve got a proposal for how upgrading of themes should be handled in WordPress 2.6 (or whenever) using a .org theme repository. Maybe more like a couple of ideas. But watch out! My first item is going to be somewhat controversial amongst theme authors.
Use WordPress Theme Options to Store Footer Text
What prevents people from upgrading their WordPress theme? Changes they’ve made to the theme file. Ignoring changes made to accommodate plugins, there’s really only one spot a theme user would really want to change and have no apparent control over in the admin area: the text in the footer. Theme authors should hand over that power.
But why? Isn’t there a theme editor already? Yes, but there’s PHP and logic floating around in them there files. Plus, If a change is made there, it’s not protected from upgrades. What about my credit? Stop worrying about it. If you’re going to release something for public use, really release it. Take the leash off.
OK. Take the leash off might be harsh. After all, I’m not advising widgetizing the area. I’m dropping in some default values, a link to WordPress and a link to my site. I’m suggesting a link back. But here’s the catch: I’m using WordPress to suggest a link and protect any changes the theme user might want to make when it comes time to download upgraded or corrected files. Changes like remove my link or, after modifications, change it to inspired by, or whatever. Making the footer text a theme option makes everyone’s life easier.
And credit’s not all that important is it? After all, if it was, theme authors wouldn’t remove the link back to WordPress in their own footers, like some currently do.
Anyway, the image above is from a working example and I mean to incorporate it into future WordPress themes, along with my sliding meta panel, and a few more carefully considered theme options.
WordPress-generated Custom CSS files
Here’s something that theme authors currently can’t do: generate a custom CSS file for every theme in
wp-content that loads after the main stylesheet. Yep, I think self-hosted WordPress blogs should have something similar to WordPress.com’s custom CSS upgrade. Maybe storing the file in
/wp-content/custom-css/themename/custom.css for editing by power users.
Again, this would just make upgrades easier. I’m betting a lot of theme changes are minor and can be handled by CSS alone—especially if you’re building with something like the Sandbox’s semantic class functions. A trip to the Theme Editor page could default to your WordPress generated custom stylesheet and leave the template files and main stylesheet to a sub-page.
When new features, major bug fixes or popular plugin supports are added to your theme—through a theme repository similar to the current plugin one—and you’ve made all your changes to the custom stylesheet you can upgrade without worry.
What’s Your Opinion?
What do you think? Editable footer text? Custom CSS for self-hosted WordPress blogs? Are these good ideas? Let me know with a comment.
Or you can vote on it. I’ve submitted the idea of WordPress.com-like Custom CSS to the Ideas forum. Vote on it there.