This is a bug fix release.

• When playing a closed game, the plugin no longer uses PHP sessions. This avoids problems with PHP configurations where output buffering is disabled (thus preventing cookies from being set correctly in the plugin) - this would manifest as an inability to post a move in a closed game. Note: this requires the WordPress nonce feature, which was introduced in WordPress 2.0.2.
• When playing a closed game, users with Contributor access or lower (or those without the unfiltered_html capability) no longer corrupt the special div tags in the post after posting a move.
• For closed games, players are now only required to have the Subscriber role. Unlike the previous version of the plugin, this should work in versions of WordPress prior to 2.2.
• Draw offers, acceptance, and refusal should now work as intended.
• A bug which allowed a player to force an opponent to castle in certain circumstances has been fixed.

As usual, here is the Chess By Blog blurb page.

And here’s the download - ChessByBlog-1.0.3.zip, 213 KiB.

Please post any questions or issues in the comments. Happy chess playing!

Another new release!. Here’s the changelist:

• Full support for Forsyth-Edwards Notation (FEN) has been added via the FEN tag. This allows for arbitrary positioning of pieces on the board.
• Fischer Random Chess (aka Chess960) is now supported. You must specify the opening layout via a FEN tag. The castling rules specific to this variant are handled correctly.
• Capablanca chess is now supported. The Archbishop and Chancellor pieces have been added. Capablanca Random Chess is also supported. Caveat: arbitrary positioning of the first rank is supported, but castling always follows Capablanca Random Chess rules (i.e. the King ends up on the c or i files). This is at odds with Capablanca-derived variants such as Embassy Chess.
• Limited support has been added for arbitrary board sizes; the plugin detects the implied board size based on the FEN tag. Note that en passant, castling, and pawn promotion makes some assumptions which change based on the board size, and not all chess variants will work correctly.
• For persistent games, users now only require Contributor access, not Editor access, in order to play the game. Note that this will only work with WordPress 2.2; users in WordPress 2.0 and 2.1 still require Editor access due to WordPress issues.
• Because of the potential castling ambiguity caused by the random chess variants, castling must now be done via the new buttons, rather than by direct manipulation of the King piece on the board.
• A bug in en passant capture has been fixed.
• The server side now correctly escapes text before posting moves to the database. Previously there were SQL issues preventing some posts from being updated correctly.
• Various cross-browser/platform user interface glitches have been fixed.
• The default icons are now 32×32 instead of 44×44.

As usual, here is the Chess By Blog blurb page.

And here’s the download - ChessByBlog-1.0.2.zip, 212 KiB.

Please post any questions or issues in the comments. Happy chess playing!

A new release, fairly minor. Here’s what’s changed:

• Now compiled with Google Web Toolkit 1.4 Release Candidate. This automatically fixes the issue whereby viewers can get to your blog from different addresses (i.e. http://levork.org instead of http://www.levork.org) fail to see the chess board due to the Google Web Toolkit’s enforcement of the Single Origin Policy. There are also some speed and size enhancements that automatically come along with the upgrade.
• The “bouncy resize” of the initial board seen by users of Internet Explorer 6 and 7 has been addressed.
• In closed games there is now the ability to offer, accept or refuse a draw; also to resign.
• Games which end in a draw, stalemate, checkmate, or resignation now automatically update the “Result” tag in the PGN.
• An issue where “+” and “++” was stripped out of the PGN has been fixed.
• The PGN parser was unable to handle moves ending in ‘=’ (indicating stalemate); now fixed.
• The one-hour timeout between page view and move post is now reset with each move.

Here is the Chess By Blog blurb page.

Here’s the download - ChessByBlog-1.0.1.zip, 206 KiB.

Please post any questions or issues in the comments. Happy chess playing!

I think it’s ready for release!

Here is the Chess By Blog blurb page.

Here’s the download - ChessByBlog-1.0.0.zip, 212 KiB.

Please post any questions or issues in the comments. Happy chess playing!

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.

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.

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!