Vintage Cocoa Blog Theme

January 14th, 2007 § 0 comments § permalink

Fry's Cocoa advertising poster from 1901
The maximization of the data-ink ratio of Tufte didn’t last very long. For the new theme I decided to look for inspiration in posters from the turn of the 20th century. I found it in one from 1901 advertising Fry’s Cocoa. (Coincidentally, our cocoa of choice growing up; I’m not such a fan nowadays.) The color palette, typefaces, and restrained Art Nouveau elements appealed to me – and there were no rounded boxes! Bonus: the advertising text was amusingly nonsensical when used out of place.

So with the theme in mind I set about making the website match, which boiled down to a few stylesheet changes, drawing the top image, and drawing the side decorative element. For the banner, the closest font I could find matching the original was Ashley Inline, published by Monotype. For the “pure, concentrated” flag I loaded a higher resolution bitmap of the poster into Photoshop, cleaned up the outline, and loaded that into Inkscape, then converted it into a path. I drew the text on top as another path, and here is the resulting SVG (Users of Firefox and other SVG compatible browsers should be able to view this directly). The decorative element on the side was also drawn in Inkscape: another SVG. There is a certain lack of detail there, since I couldn’t find very high resolution source images to trace over.

As I mentioned previously, WordPress surprisingly didn’t get in my way when it came to delivering data to the theme. I could reuse all the CSS class names I’d used earlier for the Tufte look, and take advantage of the work already invested battling floating boxes in various browsers. Getting the side elements positioned correctly was the only stumbling block (note to self: remember to use position:relative for a parent element before using position:absolute). Still trying to decide what to do about the sidebar (big empty space below it) and the footer (doesn’t match), but I think it’s now much more interesting than what was here before.

WordPress Annoyances

January 14th, 2007 § 0 comments § permalink

Switched over for only a couple of days and I’m already annoyed.

By default, WordPress pings on every edit of a published post. Given that I have 300+ published posts which I need to start categorizing, and changing categories is an edit, that’s potentially a lot of pings in a short interval; and some of the ping services will ban a site when confronted with such traffic. Installed Christian Davén’s Smart Update Pinger plugin to fix this – but I shouldn’t have to.

I scan my apache error log periodically to debug my own broken links, and to chuckle at the latest virus botnet infestation sweeping the Web. Unfortunately, WordPress has a couple of issues with 404 (Not Found) errors, and these issues get magnified when you turn on date and name based permalinks, due to the mod_rewrite rules:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule . /index.php [L]

Suppose a request comes in for http://www.levork.org/narf, narf obviously being a web page that doesn’t exist. Due to the rewrite rule, instead of being dealt with by apache (which would correctly return 404 to the browser) this gets passed to WordPress’ index.php to deal with. Here lies the issue: by default, WordPress doesn’t return 404 in the Status Code (the very first line in the HTTP response to the browser), it returns 200. WordPress does stick a Status: 404 Not Found in the response header, but this is not the same thing. I don’t believe search engines respect Status in the header, they pay attention to the Status Code. For example, I found out that google’s filename based sitemap validation mechanism will bail because part of their check relies on ensuring your website responds correctly with a 404 Status Code (otherwise, anyone could verify ownership of your web site). The fix for this is to stick:

<?php if (is_404()) header("HTTP/1.1 404 Not Found"); ?>

directly into your 404.php template file. WordPress’ default theme (Kubrick) doesn’t do this! The other related problem is to get system error logging of 404 errors (so the apache error log contains them), and Matt Read’s Log 404 plugin handles this one nicely.

If you link to an entry on your own blog with a relative url instead of an absolute one (/?p=1 instead of http://www.levork.org/?p=1), you won’t get a trackback. This is annoying: absolute URLs to your own website aren’t portable at all.

Embedding a script into a post is either very hard or next to impossible: try inserting a flickr flash badge. There seem to be plugins to deal with this, but I’ve only had to do this once so I’m not too bothered yet.

PHP is its own class of irk, but I’ll leave that for another day.

Oddly, I haven’t had any real complaint about the theming support in WordPress. It presents the right hooks to get at my blog data and mostly doesn’t get in my way – apart from a propensity to insert H2 and LI tags where I don’t want them, and for the most part there appear to be ways around that.

Blog Upgrade

January 11th, 2007 § 1 comment § permalink

It’s a new year, decided it was about time to upgrade blogging software. I still remain fond of Blosxom and its chicken wire and duct tape sensibility (check out the old colophon). I continue to use it at work, but for this blog it was starting to feel a little long in the tooth. In blosxom, each entry is a file on disk. With the plethora of text manipulation tools available on Unix, this is great for hacking, especially compared to the database manipulation route for the SQL unsavvy. On the other hand, meta information about entries becomes a real pain to deal with: date stamps, tags, and comments associated with entries have to be either glommed onto the same file and parsed back out on the fly, or kept in separate files on disk from the entry. Neither approach is as straight forward as keeping it all together in one database entry.

There was also a lack of immediacy in the old way: editing a text file, uploading, finding typos, repeat. It’s okay if I’m sitting on the same machine as the web server, but for levork.org that’s not the case. Also, I’ve been using wikis a lot lately, and editing directly in a browser form is becoming natural despite the lack of emacs shortcuts I’ve grown used to. (Speaking of which, I hear they have these text editors now that allow you to see true formatting in real time. Whizzy-wig, I think they call them. How neat!)

I’ve set up Movable Type on this machine before, but I decided to try out WordPress on another blog as a test. After getting past the MySQL setup hump, installation was a breeze, and I was impressed with the feature set compared to Movable Type. So I tried it here on levork.org: exported the RSS feed from blosxom after manipulating the story templates somewhat, removed the newlines from the resulting XML RSS file (I’m picky about word wrap), and imported that into WordPress. Spent an evening fixing a bunch of intra-site links, correcting a bunch of unicode and HTML special characters mangled somewhere along the way, reintroducing newlines into preformatted text, wrote some mod_rewrite rules to preserve old links, and here we are: WordPress and blosxom sitting in the same directory for now, with WordPress handling most things. Right now the look is boring WordPress default, I’ll have to learn how to edit the themes along the way, and I have to figure out feeds, sitemaps, and other such things along the way.

And hey – you can comment now!

Where Am I?

You are currently browsing the wordpress category at levork.org.

  • Pages

  • Archives

  • Categories

  • Flickr