Site Technical Details

Date: 7-Nov-2007/19:11

Tags:

Characters: (none)

UPDATE 1-Jan-2014
This is an article about historic technical details related to installing my site with Wordpress 2.5, which I installed in November 2007. The "LAMP" stack was something I knew I probably would not enjoy dealing with. Little did I know that the experience would be so annoying that WordPress would wind up leaving my occasional writings trapped for over six years in a system with a fixed-width theme that could barely display code samples worth a darn.
Between then and when I actually learned something about web development, I made entire websites for other individuals, bands, projects. Somehow the tedium of figuring out how to get the data out of an old WordPress just seemed like an exercise not worth bothering with. Especially since I wasn't all that convinced other solutions were better.
But for the 2013 holidays and my New Years resolution, I bit the bullet to get my data out and build a new site. I'm sure WordPress has improved, but what I'm looking for in a publishing system needs to have more of a "programming" flavor. (I know many developers who have switched to Jekyll and GitHub pages, precisely because having developer-style control with reigned-in complexity outweighs large monolithic systems that seem to have every feature in them but the ones you actually want!)
So the following remains as a time capsule of the frustrations I had to work through just to get the basic WordPress installed, which left me convinced I needed something better...
I've had to do various customizations to Wordpress in order to make it a viable content management system. Some of these relate to theming and plug ins, but there are also some outright bugs. Here are the changes I made from the default installation, and hopefully they can be useful for anyone else who is going through the motions of dealing with WordPress quirks.

Visual Changes

The theme I use is Kubrick which is the default.
UPDATE 27-Jan-2014 Kubrick has been moved to "retired" status, I've updated the link
Here were the changes I made for visual customization, and I tried to keep it minimal.

Manual Bugfixes

The next set of problems I had to fix were related to bugs in WordPress, of which these all apply to the current version (2.3.1). For whatever reason, they haven't been fixed in the default installation:

Plug-ins

I had heard a lot about WordPress's plugin architecture. After looking at it, I'm not so sure I'd call it an architecture, it's really just some haphazard hooks. You find that there are ordering problems and cases where plug-ins do not work together because they both try to override the same hook, or are run in the wrong order. Plug ins modify the source of Wordpress when they install in ways that are irreversible. Despite this insanity, you can at least see what's going on... so I don't feel so bad about installing this set:

Turn off the Visual Editing, Now!

Finally, I will mention something I should have said up front—if you're savvy at all about HTML, TURN OFF THE VISUAL EDITING. It will break your pages. Even if you are in the code view and ignoring the Visual Editor, it will do bad things to your XHTML so long as it is turned on at all. This is maddening, because one would think editing in the code view would encourage WP not to mess with it:
After this is done, the only thing you have to worry about is that WordPress will still inject BR elements at every line break in the output. So if you are entering delicate XHTML that would be confused by the appearance of a BR, don't hit enter in between lines inside that construct.
There are my tips so far. I will try to keep this updated as I change technologies or make new findings. I would like to thank my hosting provider: Eric Shalov, for his server + administrative support.

Please subscribe to the Feed Icon Atom 1.0 Feed or use Feedburner Icon Feedburner to receive updates as they are posted!!

comments powered by Disqus