Public and Private Code

A friend and I are working on a WordPress theme for public release under the GPL, and I have to say, it’s a lot more work than doing one for private use.

The theme I made for this site is pretty hackish in places. I do plenty of stuff by hand, just moving and replacing files via FTP, and any problems that come up can be worked around by fiddling a little with the code.

However, if I released my site theme for public use, people would instantly run into a number of problems. The script that shows recent posts in the footer would crash, for starters—if there are fewer posts than it’s trying to display, it throws a hissy fit. I had enough articles in my back catalogue that the footer script always ran, even when I’d just launched the redesign. That wouldn’t be the case if someone had just installed WordPress, so of course it had to be fixed.

If they wanted to use a different header image, they’d have to go into the header file and change the code. All of this is too much of a barrier for people who aren’t web developers, and just want a nice theme for their site. Then there are plugins, which are even worse—plugins are inextricably tied into a lot of this site. All those dependencies have to be taken out.

In other words, public code needs to be a lot more rigorous than private code. There are more variables, because more people will be using it in different ways. Every situation needs to be coded for in advance, since once it’s out there I can’t hack it on the spot to fix any issues that arise.

Moreover, a publicly-released WordPress theme needs to be usable by a less technical audience. Installation should be just a matter of uploading the theme and selecting it. People should be able to change the header image inside the admin panel. If they turn trackbacks on, trackbacks should show up. There is, quite simply, more work to do: more contingencies to account for, more problems to solve.

All that said, we hope to release it in a few weeks’ time. Those who’ve asked for a public version of this site’s theme will not, I hope, be disappointed.

6 responses

Well, thankfully, a lot of plugin dependencies can be eradicated via PHP’s function_exists function. That one’s a lifesaver.

/me gets back to work

~ ceejayoz #

I never thought I would say this, but I know exactly what you mean. I hacked the shit out of my Chapstick theme, and then proceeded to release it. There were so many errors it wasn’t even funny. Luckily function_exists cut down on alot of time that would have been otherwise wasted.

Can’t wait to see the theme!

~ Andrew Hamann #

I’m working on a new theme for myself right now. The way I do my own theme is copy kubrick and then each file I work on I strip down to the bare PHP and start again. As I’m doing this I find that I will just delete things I never use just to tidy the place up. Things like comments being closed or password protected posts I completely take out of the code because I just never use them.

This is really bad if I’d ever want to realease a theme. Sometimes I come accross a time when I do want to realease one but quickly dismiss it as being way too much work.

~ Jim #

Exactly, Jim; that’s what I’ve done with pretty much all the WP themes I’ve done to date (four, of which three have seen the light of day). To be honest, the amount of work I knew it would be if I did it properly was one of the major factors I haven’t released one before this.

~ Benedict #

i quite enjoy this layout and look forward to seeing what you produce!

~ rabsteen #

Thanks, rabsteen; I started out trying to make the new theme at least slightly different from this site’s one, but along the way I’ve tightened it up a lot more and improved on various things that weren’t thought out as well as they could have been. I’m quite looking forward to putting it out there in the WordPress ecosystem.

~ Benedict #