Well this is the first time I’ve really mentioned Kitchen Sink HTML5 Base anywhere except to friends and whoever might have stumbled onto the source code and wiki at github. But I’ve created a development “platform”, you might also call a “framework”, for developing and enhancing WordPress theme and plugin development.

It’s called Kitchen Sink HTML5 Base. So named because is indeed full blown HTML5 madness born out of HTML5 Boilerplate, but most important is the BASE part of the name. I am still relatively new to WordPress development but once I got past some the hoops and idiosyncrasies of WordPress development I began to fall in love with how well the end-product (your website ;) works.

And as if the universe were saying do more WordPress sites I started getting more requests specifically for WordPress development and got hooked up with some new agencies. So over time I had cobbled together a crude but highly effective base theme for quickly taking a client design and returning a finished custom theme. But after so many, while my base theme and each subsequent theme was getting more feature rich and stable, the old ones were stuck in time with whatever idea/notion/concept/bugs I decided to use that week.

At some point near the end of December I decided it was time to finally figure out a better way.  The biggest issue I had was that there was no quick way to update old custom client sites. I couldn’t post their themes for distribution and update them through the WordPress directory. And everything I saw in existing Parent/Child theme frameworks seemed somehow too  much, too little, too confining, too expansive, all without being simply a way to make ONE custom theme and somehow update just the core functionality.

And yet after much debate and research I caved and opted for some kind of generic Parent theme that wasn’t really a theme at all. Just all the core stuff that I wanted/needed for 90% of all the themes I had made so far, but in such a way that could be distibuted and updated through the WP update system.

I started the process and as it turned out it wasn’t that difficult at all to just take my existing development base “skeleton” theme and do exactly that with a Parent/Child theme methodology.

Then while twiddling around getting close to wrapping it up I was writing a description for the README that I would need to submit it for theme review at the WordPress directory. I wrote something to the effect of it being “less a theme a glorified theme plugin…” And I stopped.

That is what it was. It was a plugin. It wasn’t a Parent theme at all. It just had a bunch of shit I thought every theme should have available to use but contained no meaningful structure. And that’s when it hit me, “Why not just make it a plugin.”

Why not indeed. There are myriad reasons to not do that. By moving a lot of basic theme crap you need to do everytime (and are going to everytime) like add_theme_support(‘post-thumbnails’), it actually defies all convention, doesn’t pass the theme-check validation plugin, and where some people long for a day where themes quit being plugins, I’m turning a theme into a plugin (ah the irony). Then there is the problem of plugin dependent themes. There is no such thing at least not at WordPress.org. Forget the thought of plugin dependent plugins.

But the more I thought about the more I realized I didn’t care. It was a good idea (I thought and fortunately still do after finishing the first non-demo theme with it). So I further tore my Parent theme apart and turned that into a plugin.

And like magic it worked.

And then I realized in this context it was great big flaming ball of poo. Well that’s extreme, but I realized that in the context of a plugin there had to be better ways of doing some of this stuff. It was about that time that I discovered WPAlchemy_MetaBox by Dimas at farinspace.com. It is a brilliant piece of work. You need metaboxes? WHAM! You got metaboxes. So simple in it’s concept, so feature rich in it’s implementation. At about the same time as all this my former business partner who had used my development base theme for a couple of sites and liked it decided to help out a little bit with my crazy plugin idea and the next thing you know we’ve got the beginnings of a full blown WordPress Development framework.

Though it really isn’t a framework as a cohesive set of modules that can be included and utilized by a theme or other plugins to quickly add extra functionality such as metabox or an options page or ninja style consecutive widgetized areas in a couple of method calls and the occasional settings array.

And now a month later it is nearly ready to be officially tagged Version 0.1 Kitchen Sink HTML5 Base. I’m skipping any pretense of calling it Alpha or Beta. It’s version 0.1 for criminy’s sake. But wow, I think this is a pretty slick and pretty awesome almost version 0.1 for anything calling itself software.

I’ll talk more about what it does, how it does it, and why it does it in the future. But you can check read the fairly comprhensive wiki I wrote for it at github and suffice it to say that the goal is to do for WordPress development what HTML5 Boilerplate offers for consistent optimized web development in general.