Archive for the 'WordPress' Category

Out with Wordpress in with Postword

At the risk of becoming part of something trendy (which my nerd contract expressly prohibits), I’ve finally ditched Wordpress in favor of static solution. Unlike everyone else though I’m not ditching it for performance reasons, because honestly, I don’t get enough traffic to bring down London bridge, which, according to a song I once heard is constantly falling down.

No, what prompted this change was my Wordpress install getting hacked for a third time (to inject spam links, of course). It’s not entirely Wordpress’s fault; each time my version was out of date, despite Wordpress making updating to the latest version super easy. Unfortunately I don’t go the Wordpress admin panel every day to check for updates, so I’m routinely out of date.

All of which to say, I needed something other than Wordpress to get around my update delinquency. Specifically here’s what I wanted:

  • Little to no code running on the server, with a strong preference for none. No database, either.

  • It should generate a static site, from flat text files.

  • It should be able to import all my Wordpress entries

  • Support the Wordpress site/link structure so that it wouldn’t break existing links into the site.

And a couple of nice to haves:

  • Support some version of Wordpress themes, or at least make it easy to port them.

  • Work with MarsEdit

In other words, I wanted Wordpress without the Wordpress.

There were a couple of solutions that got close, but none that did all that I wanted. So, being an engineer, I decided to write my own, which I codenamed Postword. I actually started the project back the last time I got hacked, and even used an early prototype for the blog on Hearts & Tactics.

Postword is more or less a collection of Ruby scripts. It has one to take a Wordpress XML file and convert it into a bunch of flat files (one for each post) that can be processed later by the build script. The flat files are nothing special; they have mail like headers for the categories and title, and then body which is just text with some HTML markup allowed. The build script takes these flat files and builds a full site that looks like Wordpress site structure wise. The script is unique in that it supports the idea of themes, whose API just happens to be the exact subset of Wordpress APIs that my custom Wordpress theme happens to use.

And that’s all Postword was up until a couple of days ago. But if was going to use Postword on this site, which I update somewhat frequently, I needed to reduce the friction. The first thing to do was to write a publish script that pushed the local static site to my server via FTP. I wrote my own script in Ruby, which actually turned out to be not that bad, since I could make a lot of assumptions. The important one was that the local site was always the truth. Which meant if the local and remote ever differed, the local overwrites the remote, and if the remote had a file which the local didn’t the remote gets deleted. In effect, the site becomes self-healing.

The last piece of the puzzle was create a local server that MarsEdit could talk to. MarsEdit supports a lot of different APIs, so I had to decide which one to implement. Wordpress was an obvious choice, but it offered a lot of functionality to I didn’t have or want, plus it was more complex than the others. I decided on MetaWeblog, with the Blogger API as a fall back for when MarsEdit tried to delete a post. It was surprisingly easy to implement, since almost all of the functionality was already in the other scripts, and Ruby provides an XMLRPC server out of the box.

The really nice part of all this is I now have the entire source to this site (flat post files + images + build scripts) in one Mercurial repository. I can download that and publish from any machine, as well as have instant back ups.

Not to say Postword isn’t without its flaws. The build script is slow; it takes a little while to generate all those archive pages that Wordpress creates on the fly. And if the build script is slow the publish script is glacial. When posting from MarsEdit, I can’t actually call the publish function after building the site, because MarsEdit will time out on the HTTP connection. That said, the pros easily outweigh the cons for me.

All in all, I’m tickled pink about how Postword turned out.

Formatting Objective-C code with the HTML code tag

You might have noticed, especially given the last post, that the code formatting on this blog leaves much to be desired. I’m trying to rectify that, but I’m not quite sure how to do it.

I’ve always assumed that when presenting code, I should use the the <code> tag. Unfortunately, the default formatting of this tag is indeterminate at best. From trial and error I’ve determined that it’s usually best to put each line of code in its own set of <code></code> tags, otherwise formatting gets really wonked. I’ve also found, depending on the CSS, I might have to put a <br> after each line of code, otherwise my nice, pretty function all ends up on one line.

And this completely ignores indented code. There seem to be a couple of ways to making indentation work. The first is to use the white-space: pre; CSS rule and make sure the tab characters are in the <code> tags. The second is to use the text-indent CSS attribute for each line of code I want to indent.

None of these options are easy or simple, which makes me think I’m doing something wrong. Are there are any web designers/HTML coders in the audience that know the proper way of doing this? Surely it’s not intended to be this painful.

The problem with formatting code on this blog has led me to the conclusion that I’m probably going to have to ditch my current WordPress theme. Sure it’s pretty, but it does float: right on my images with a rule that has high specificity, making it very difficult to not float my images to the right, which is what I usually want. It also has a fixed width, which doesn’t really mix well with my code examples, not to mention it doesn’t style the <code> tags well.

Unfortunately I haven’t been able to to find an appropriate WordPress theme that will fit my needs. I’d really like a two column layout, with a fluid width, and, if it’s not too much to ask, decent <code> tag handling.

PollPress WordPress Plugin

Download: PollPress 1.0
Subversion: PollPress 1.0

Regretfully, PollPress is no longer a supported plugin.


PollPress is a plugin that allows you to add polls, similar to sites like slashdot, to your blog. Poll creation and management is very similar to creating and managing normal posts. The plugin allows users to vote on the most recent poll from the sidebar, and the poll results are displayed in a post, where users can comment. The plugin also adds an archive page for the polls, where users can browse and vote on older polls.


PollPress 1.0 requires WordPress 2.0.4 or higher, and MySQL 4.1 or higher.


  1. Download the PollPress plugin.
  2. Extract the plugin from the zip file. You should get a folder named PollPress. In it you will find a file called readme.txt and the actual plugin folder called pollpress.
  3. Upload the inner pollpress folder to your plugins folder, which is usually called ‘wp-content/plugins/’.
  4. From the Plugins administration panel, activate the PollPress plugin.
  5. To install the voting booth on the sidebar, you need to add some code, <?php pollpress_voting_booth(); ?>, as described next.
  6. In the administration panel, click the ‘Presentation’ tab, then the ‘Theme Editor’ tab.
  7. In the theme files list on the right, click on ‘Sidebar’.
  8. In the code, find the desired location in the sidebar to add the voting booth. At this location, insert the code <?php pollpress_voting_booth(); ?>. If the sidebar is like most, you will need to put it inside list item tags, like this: <li><?php pollpress_voting_booth(); ?></li>
  9. Press the ‘Update File’ button.


Writing and managing polls work almost identically to writing and managing posts. PollPress installs administration panels under Write > Write Poll, Manage > Polls, and Options > PollPress. The sidebar of the site will always show the voting booth for the most recently published poll. PollPress will also automatically install a static page called ‘Polls’ that lists all the polls that have ever been published. Users can use the Polls archive page to find old polls and vote on them or view their results.

Writing a poll is simple. Navigate to the Write > Write Poll panel. Enter a title and, optionally, your first poll option. Press ‘Save and Continue Editing’ or ‘Add’ to save the title and option and continue editing. All the extra settings such as Author, Timestamp, Category, etc work identically to a post. When you are ready to publish your poll, press ‘Publish.’

Managing your polls is the same as managing your posts. The only difference is that instead of going to Manage > Posts, you go to Manage > Polls. You can view, edit, and delete polls from this panel, in addition to managing comments posted to the poll results.

The options for PollPress are minimal, and are found in the Options > PollPress panel. The options allow you to change the color of the bar graph on the poll results page. The options page also provides a button to delete all the polls. Because PollPress uses a filter to generate the poll results, if you deactivate PollPress all your polls will begin appearing as regular posts, but with no content. So if you wish to uninstall PollPress, press the ‘Delete all polls’ button first, then deactivate the plugin.


Click on a thumbnail to see the screenshot at full size.

PollPress voting booth Voting booth Poll results Poll results
Polls archive pageArchives page Writing a pollWrite a poll


PollPress is no longer supported. I will not be fixing bugs or adding any features. The code is open source and can be improved by others.