Bill Erickson, that master WordPress genius that he is, has brought forth a new plugin that can change the way we think about WordPress. He wrote this amazing post describing how and why he puts a site’s main functionality into a plugin. I think this is an awesome way to keep a custom post type registered even though a new theme is activated. It’s also a better solution than using the MU (must-use) folder that is dropped / created in the plugins folder. I am truly grateful for a man like Bill that keeps progressing WP. Sir, Thank You!
See what this plugin does is simple. If you want to register a new custom post type, or sidebar or anything really with out losing them upon activating a new theme, you use this kind of a plugin.
Here are my concerns.
Let’s say that a WordPress site owner has some specific elements that they want built into their site. How we used to solve this problem was simple. Drop the code into the functions.php file inside the theme. Then based on what was done, we might need to create a new file for a custom post type, or depend on a custom post type to be already built into the theme in order for something like a meta-box to be relevant. If a new theme was activated with out these available options, the developer needs to go in and create those. Now, I’m not complaining. That usually meant more wok for me that I can bill my clients. Hell, I like that idea to tell you the truth. And I’m a nice developer that will charge less money to recreate functionality into a new theme no matter how long it will take. So chew on that for a second.
You may have not read my article on Why Theme Demonstrations Suck. If not, let me sum it up. Not all theme’s are created equally. Even if it’s by the same developer or development company, there are elements in a theme that one might lose if a new theme is activated. Now it goes way deeper than that, but that sums it up. So Bill Erickson’s plugin solves that. But the issue is that if you want to have a custom post type displayed in a such a way, you have to create a file for it and hack it up and drop it into the theme. Even if you include it into the plugin, and enque scripts into the header, you still have a problem.
Each theme page / post template usually does two of three things. They either call in the header.php file, the footer.php file and / or the sidebar.php file. Now that’s all fine and dandy. But the issue is that those files include “class names” or styles that are baked into the style.css file. Maybe even somewhere else. So even if you have a plugin that does everything for you, there is always going to be some kind of work to be done upon activating a new theme.
Now it’s my common knowledge to always try to use the same naming structure with all of my templates that I build. Of course the div name for where all of my content is going to go in a page template is going to be called content. Most themes do that already. But what happens when a new user to WordPress asks Myself, or Bill, to build them some custom work and then changes the theme 6 times a year and demands that we fix the problem that they should be thinking about, but chose to be ignorant too?
What happens is that they get an email containing the words “Hourly time billed” “or may result in paying more money for time spent developing”.
So how do we solve this problem? It’s very simple. We need to write better articles that educate the end users or “New Users” that even though WordPress is marketed as a install and go CMS, there will always be road blocks in the way based on specificity that needs to go into the theme.
What You May Be Thinking:
Russ, this plugin is mostly for development use only by a developer. More than likely clients, like Coca Cola and Ford, will not change a theme every 6 months. I understand that.
Russ, you’re already over thinking this. This is a simple fix for something that is not baked into the core of WordPress. Again, I understand that.
Russ, what’s your point already?
My point is that we have these amazing guys like Bill Erickson solving problems for something that should be in core, but we’re forgetting that there are larger issues inside WP that need to be addressed. For one, the more specific a theme is the less you can really add in “one size fits all” plugins. Two, there are so many theme developers and theme’s to choose from these days. Most of these themes have very little to no checks going on to ensure that the theme will not break upon a plugin activation, or even meets the standards set by WP in the first place.
So how do we solve this problem?
We need to be less dependent on themes, and more dependent on plugins to do the heavy lifting on our sites. WooCommerce is a great example of this. Your theme should allow you to add in the basic things like a logo and footer options. But if you want something done, you should have a plugin that adds in the functionality and then the code depends on a style sheet in the plugin and not the theme. Even then we have Problem. I use Bootstrap in most of my problems. Someone else may use Skeleton in theirs.
So if we’re going to be more dependent on plugins or themes, we really need people to stick to a theme shop like StudioPress. Because no matter what, 99% of the time, if you use a theme and then switch to a new one, all of the meta box info can still be relevant to the theme because Genesis allows us to hook elements into the theme.
So I guess what I’m saying is this: before you choose a theme because of the bells and whistles, we need to be coming up with a plan of attack for your site. That way, you can find a theme or a developer that you can stick with.