Hello – here’s the refreshed blog. I’ve decided to revert to a more typical blog format, after many months of soul searching on the issue. I previously had a layout based on a framework we used at interconnect/it for a couple of clients
Well, it’s a lovely theme, for starters. The typography is pretty good. The archives page is brilliant (check it out) and should be the standard bearer for all themes archive pages.
But the real question for many, I suspect, is why I’m not using an interconnect/it designed theme. Well, for starters, interconnect/it hasn’t produced an off-the-shelf theme in years. It’s just not our business. So rather than use a product of ours, we’d have to spend good and valuable time on creating a new theme. And, well, why would we want to do that?
Lots of reasons, actually. I could have a theme coded at the office that really shows off what we can do. But the problem with that is that there’s not much need. My blog is not an important one. It isn’t about WordPress (most WP related content will be on our company site, not my personal one) and it just doesn’t get much traffic.
I run a business. Its purpose is to make money, employ five people, and, with a bit of luck, turn a reasonable profit. Its job is not to service my ego or make me look good. A really good theme costs the equivalent of around £10k-£20k of chargeable time to design, code, test and implement.
Given that we’re turning work away, I thought “why bother?” And decided to go shopping for something.
So What’s It Like?
It’s actually quite weird using somebody else’s theme. I actually tried a few out and here are the things I learned that will hold us in good stead.
Themes don’t do enough to make life easy.
No really, they don’t. One of interconnect/it’s biggest challenges is making sure that WP is as easy to use for clients as possible. This means following standards, but it also means using some little tricks that help out – for example, registering and setting plenty of different image sizes, and setting/over-ruling whatever the media settings say.
Migrating WP content really sucks.
There’s a fundamental flaw with the default WP export/import. If you have inline images, although the importer has the ability to download and attach the image in your new site it won’t change the links. And if you do a search and replace, and your image sizes have changes, your lost. Totally – the img tag will point to a file that doesn’t exist.
So what do you do? Well, usually if I’m moving a site from one server to another, even switching domains, it’s a non-issue. I have my tools. But if you’re starting from fresh and working like an end-user would then you have to go through every single damn post in order to fix the images. Every post with an image in it. That’ll take a while.
If you’re really geeky, you’ll sort it, but it takes time. Way too much time. This kind of stuff needs to be sorted and it’s something we may look into as a contribution to the WP project.
Some Plugins Leave Lots of Crud
The reason for a reboot was that I felt that my site’s DB had been filled up with all sorts of crud. Lots of plugins create tables, leave options, and so on. Surplus tables have little impact, but they clutter the place up. But options, lots and lots of them, do have a minor performance hit, and they add up.
Other plugins leave hooks, don’t deactivate properly and so on. And over the years, I’d been through an awful lot of plugins. The site hadn’t been redone since WP 2.0 had been set up on it. I felt it was getting sluggish.
So… there are beautiful and amazing themes out there, and WP is wonderful, but there are little things that could make life just that bit better. Better migration tools, a better system of managing images within content and their migration, and a better system for activating themes so that image sizes are better handled.
Is it a lot to ask? Well, we’ll see what we can do about that!