Why I Should Stop Doing Web Development

MAMP does make my failure come faster, at least.
MAMP does make my failure come faster, at least.

A few weeks ago, I got home one evening all jazzed up to hack the Carrington Theme on a local web server I set up on my Macbook. I had some definite ideas for how I wanted the front page to look, so I wanted to edit the theme and achieve my vision.

Three hours later, all I had to show for the effort was having cut it down to a single sidebar and moved that sidebar over a bit.

It all makes me feel pretty stupid, because I work with computers for a living and feel like I should be able to “just get” this.  After all, I’ve built numerous web servers, personal computers, and am experienced with a variety of different operating systems, programs, and web platforms. But when it comes to coding a page, once we get beyond HTML, I’m practically a goner.

That’s the main reason I began using Content Management Systems (CMS) after all. Beyond a simple, relatively ugly page, I can’t create that good a website.  I should just stick to creating the content that the management system manages.

One of my resolutions this year is to write and publish a book, and I’ve got a few other projects that will hopefully come to fruition that I’m not ready to reveal yet. I’m not going to get all this work done if I keep screwing around with stuff I’m not good at, though. If I invest all of my time and energy into something I’m not good at, like web development/design, then there’s no time/energy left for the things I can do well, IE writing what I want to write.

It has become a guiding philosophy for me in the last couple of years that one should gauge and recognize their own strengths and weaknesses, learning to get the most out of what they can do, rather than trying to exceed their limits or waste time doing things poorly. The only metaphor I have for this is in regards to fantasy fiction and wizards: a low-level wizard who knows how to use their power well will be able to apply it creatively and to great effect. In so doing, they may outperform a significantly more powerful wizard who is not creative and doesn’t use their power wisely; instead, the more powerful individual wastes their power because they don’t know how to use it, and the comparatively weaker of the two outshines them.

I can accept not being that great at something, but it means that I need to stop focusing on those projects that I just can’t do well. I’ll produce content, and if I have to someday, I’ll hire someone else to do my web development. For now, WordPress and Alex King’s contribution is good enough for me, and with the few minor tweaks I’ve made to it, it’ll manage my content just fine.


Just a quick post about my foray into Lightbox. I started messing with this while writing about Flickr the other day, and after a bit of tweaking, I got it working.

You could just follow the steps on this page, but installing the plugin for WordPress is probably easier. The first, however, will allow you to use Lightbox wherever and however you like, while the latter will only work inside WP.

I, of course, followed the steps to do it manually (mostly because I didn’t find the plugin until after I was done and had it working *sigh* ). Something I discovered that might be of interest to you is that, while the instructions technically allow Lightbox to work, it 1) doesn’t tell you everything you need to do and 2) doesn’t necessarily work right on blogs.

First, when you upload and extract the files, it is assumed that you’re putting those in the root of your web server. I had put them elsewhere, and subsequently it wasn’t working.

However, because they assume root (once you get them moved there), going to a specific blog entry will prevent Lightbox from working. Essentially, all the code in the JS and CSS files point to root or ../images for everything. Which is great, and works just fine on my main page (http://mstublefield.com), but when I go to a blog post (for instance, https://mstublefield.com/blog/2008/09/24/why-i-dont-use-flikr/), going to ../images actually points at https://mstublefield.com/blog/2008/09/24/images (the ../ being “go up one level”).

So, I went through the JS files and the CSS file and changed the links from dynamic to static. Therefore, instead of ../images/close.png, it became https://mstublefield.com/images/close.png. Instead of js/whatever, it became https://mstublefield.com/js/whatever. This allows Lightbox to work inside specific blog posts, as well as on the main page. The only files that need edited are the lightbox.js and the CSS file.

Secondly, the CSS file wasn’t quite working for me. The instructions say to put it somewhere and their files will point to it. Instead, I had to manually copy/paste the CSS and append it to my main stylesheet. This seemed to work a lot better for some reason. Maybe it’s that I didn’t have the CSS in the right place, but regardless, it was easier just to copy the code over.

Between adding ZenphotoPress and Lightbox, I’m pretty excited about adding more pictures to my blog 🙂

Scrolling code display boxes of doom

Why can’t anything ever work as advertised?

So, I’ve written a couple of tech articles for the next couple of weeks (scheduled to publish on the next two Tuesdays) and they had a few code snippets in them. Therefore, I thought I’d find a nice way to display that code, maybe put it in a box that preserved its formatting, and if the line was too long would present a horizontal scrollbar instead of breaking the right margin or wrapping the code.

I first tried the IG:Syntax Hiliter (it frustrates me to no end that it’s not spelled “Highlighter”), which is supposed to be the first, greatest, most original plugin for WordPress that is intended for this purpose. But when I used it, it refused to present my code in a visually accurate fashion. Or, rather, it was too accurate: it converted my symbols to their ASCII equivalent and displayed boldly that this was Plain Text mode.

You could click on Plain Text and change it to HTML, which made it look nicer, but I wanted it to default to HTML. What’s more, it didn’t behave regularly; sometimes, the code would be accepted and displayed, and other times it would be stripped out and deleted. This isn’t an issue with the plugin so much as it’s an issue with WordPress, which strips PHP from blog posts as a security measure. However, when I’m trying to post PHP to give an example, that’s pretty damned annoying.

I then tried WP-CodeBox, an off-shoot of the “Hiliter” (every time I see the word spelled that way, I think it says “Hitler”) but one that seems to be preferred by a lot of people. Unfortunately, its author’s website is in Chinese or something, has major faults on it that kick me to a partial TinyMCE window, and the plugin failed completely. I couldn’t get it to do anything.

I tried 1-2 others before finally giving up. What irked me the most is that I had it looking just fine before using pre-tags and/or blockquotes, and these plugins (even when they semi-worked) looked worse. If I included code as a regular part of this blog, I would definitely find a solution (and I suspect I’d just develop it in-house using CSS, which seems far more reliable than the plugins geared towards this task), but I just don’t care anymore.

Bugger it.

WordPress Advanced Editor

Because I’m so content-focused with my blog (focusing largely on writing), I really love the advanced editor in WordPress, especially as of version 2.3. I do the vast majority of my writing live inside WordPress, where it saves every 30 seconds and I have a character map at the click of a button in the toolbar if I need to accent something. Links are easy to insert, I can pull pictures in easily, and it fits my purposes.

But a friend of mine is an actual web designer, and as such, he does a lot more on the visual and code side of things. The advanced editor in WordPress gives him quite a bit of grief, particularly when he switches over to the Code tab and enters some custom HTML, then goes to the Visual tab and sees that WordPress has “cleaned” his code, effectively breaking what he intended his post to look like.

The code cleaning feature in WordPress’s TinyMCE advanced editor is there to help users protect their theme. By ensuring that code is encapsulated and formatted “correctly,” it keeps WordPress pages from breaking. Unfortunately, it also often makes changes to one’s intended code, frustrating the user.

Stephen at Scratch99 has a great article about how to address this problem, and I suspect that Ryan will take the simple method of editing the TinyMCE javascript file and just turn off the “clean code” feature.

Turning the Advance Editor Cleanup Off

If you often enter your own HTML, but still want to use the Advanced Editor, then you might want to consider turning it’s cleanup option off. I stumbled upon how to do this on Thu Tu’s Smacking WordPress Editor.

Note: if you do this, the Advanced Editor will not do any cleanup. If you make errors in your HTML that break the theme, you’re on your own! If this happens you may not be able to edit the post anymore – the only solution may be to close the browser, go to the manage posts page again and delete the offending post.

To summarize how to turn off the advance editor cleanup:

Download the wp-includes/js/tinymce/tiny_mce.js file using an FTP program and use a text editor to change the following (near line 167) from:

this._def(“cleanup”, true);
this._def(“cleanup”, false);

Save the file, then ftp it back up to the server, overwriting the original.

Note: you need to delete your browser cache before this takes effect. For Internet Explorer, click Tools on the menu, then Internet Options, then Delete Files. For Firefox, simply press Ctrl+F5. For other browsers, sorry you’re on your own, but it should be straightforward to do.

As for me, I’m going to keep writing just like I always do. Now, if I could just find a decent way to format poetry correctly in WordPress…