The default javascript API uses document.write, which isn’t a DOM method and hence is not a method of true XML documents. It’s not a new issue either, wp-recaptcha has had a history of breaking XHTML. The thing is, the WordPress plugin (which uses the PHP library by the recaptcha people) has an option to “Be XHTML 1.0 Strict compliant”; but this only fixes the use of iframes and noscript!

Updated: pushed fork to github

Under firefox, you get an error like:

Error: uncaught exception:
[Exception... "Operation is not supported"  code: "9"
 nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)"
 location: "http://www.google.com/recaptcha/api/challenge?k=xxx Line: 12"]

While under Chrome it’s

Uncaught TypeError: Object #<a Document> has no method 'write'
api.recaptcha.net/challengek=xxx

The real solution is to use the reCAPTCHA AJAX API, which for whatever reason isn’t exposed in the PHP library. You can grab my xml fix for wp-recaptcha from github.

The most annoying way was that the options I’d configured up the top of the file weren’t having the desired effect. I wasted the better part of an hour in debugging until I recalled how horrid PHP scoping was. It was a simple fix.

--- rest.php	2008-01-03 00:28:23 +0000
+++ rest.php	2008-02-04 09:20:59 +0000
@@ -95,6 +95,7 @@
  */
 function reST($text) {
   global $rst2html;
+  global $rst2html_options;
   global $cachedir;
   global $usepipes;
   global $tmpdir;

Additionally, the handling of wordpress “more” directives was quite fragile. They broke with the default wordpress theme. Matthew seems to have incorporated some of the suggestions from pupeno, but there are a few problems with that post:

• I think pupeno forgot to change the $prefix when he wrote he was changing it for debian.
• The suggested link processing is *way* too broad; it’s only meant to be used for “more” links, and the way it is it will clobber any linky-looking thing regardless of context.

I sent a couple of patches to Matthew Scott; hopefully he’ll apply
them. In the meantime, I started my own rst-wordpress branch on launchpad.

Despite all this, I feel a more robust solution is in order, probably involving driving docutils directly via python, and maybe even using docutil’s XML output with XSLT.

What did I want from my blogware? Well:

• a minimal markup for inline formatting
• the ability to copy and paste code without having to escape it or encode HTML entities
• extending the code to be fun…

The only decent markup language I’ve come across is reStructuredText, although I can tolerate mediawiki’s. It does things right:

• the markup is pretty close to what I’d use if I was posting in plain text
• you can escape the markup if you need to
• you don’t need to escape literal blocks (apart from indenting them)
• it supports higher-level things like metadata, xrefs, citations

The only problem is that it’s very python-centric. Even though it’s semi-standardised, it evolves as the docutils dev team add features to the docutils processor. There aren’t processors for perl, ruby or C, so it’s not the why-aren’t-we-using-this-it’ll-work-ootb solution that, say, YAML is in its domain.

The plugin that sealed the deal with wordpress was reST for wordpress. It is a hack: it calls “rst2html“ and rips the body out, and recommends you turn off the “correct invalidly nested XHTML automatically” feature of wordpress (although this may be to avoid pre-processing, rather than because the rst output is broken).

I really wanted hobix to work. It wasn’t going to happen. Apart from the markup issues, its maintenance future doesn’t look bright. A bunch of stuff is broken, and from my exposure to that code base, adding my own plugins is likely to be anything but fun.

The motivation to post is at the critical lower bound as it is, without procrastinating about mending the posting-platform.