With WordPress you have several different ways to package and sell themes. I want to talk about why I choose the direction we did, and hopefully it spurs some debate that could lead to better practices. As it sits now the options are all over the place.
Single Theme Method / Drop In
This is the easiest, and most idiot-proof method of shipping a theme. The user installs one folder, and they get all the functionality in that. The problem I have with this, is loading code that won’t be used. I really just don’t feel comfortable shipping a theme where even 25% of the code isn’t being utilized. The same thing goes with a “drop in” framework. I do not want to load a bunch of code that won’t get used, and you have to load the code to take care of the crazy designs and interactivity across unlimited child themes.
Do you see the problem here? We’re creating our own walls by limiting the childs functionality to what’s the parent or drop in framework can do. So then the next logical step is the parent/child theme combo. The code in the parent isn’t in the child theme. Means the child theme is super lightweight. This means the parent can be updated without affecting the child theme. However this very logic is what brings in confusion for the end user. Now they have to install “two themes.” But since this is the best practice, this is the method I went with.
So how do you customize the child theme? Apparently, you edit the child theme. Seriously? No way. I need to send updates to the child theme so anything users will do will just get fucked on an update. So O.K, a “grandchild” theme. Since those don’t exist, we can create it inside a plugin. So, I wrote the Child Customizer plugin.
You create a directory in ‘wp-content/cc-templates’, and you copy the templates from the child theme, to that folder. Make your edits there, and the plugin will use your templates instead of the childs. The plugin also will load a style.css file, if you drop one into the same folder. The plugin will autoload your css file so you can make tweaks to the child theme there. This plugin basically offers a full-proof method to edit WordPress child themes without directly editing the files.
I tried submitting to the WordPress repo, and was told:
Keep in mind, we may not approve your plugin. We have serious doubts about it’s use, since … the way you customize a child theme is to edit the child theme. Making a plugin to customize the child theme seems counter intuitive. The base theme must be there for the child theme to activate, so it’s functionality is assured.
So what is right, and what is wrong?