Mediawiki2HTML

I was asking a while back if anyone had a bookmarklet or service to turn MediaWiki markup into HTML. No-one did, so I’ve built one. I’ll be using it to turn my internal wikified Mozilla Foundation status reports into text suitable for posting here.

It’s all very web 1.0 – note the “cgi-bin” in the URL. You won’t find any XMLHttpRequests here. It’s written in Perl. All the hard work is done by the excellent Text::MediawikiFormat Perl module.

One slightly funky thing is that the scripts know how to serve themselves up for download. This means I don’t need to keep two copies on the webserver. It’s very simple (five lines of code) but I’ve not seen it done before.

7 thoughts on “Mediawiki2HTML

  1. > One slightly funky thing is that the scripts know how to serve themselves
    > up for download. This means I don’t need to keep two copies on the
    > webserver. It’s very simple (five lines of code) but I’ve not seen it
    > done before.

    i normally create a hard link, so i have .cgi and .txt filenames for the same content.

  2. Hi Gerv,

    Nice work! You should get rid of that custom form-parsing code – ugh! :-)

    use CGI::Lite;
    my $cgi = new CGI::Lite;
    my %FORM = $cgi->parse_new_form_data;

    David

  3. The custom form parsing code is a legacy of the time the original script ran under safeperl. safeperl doesn’t allow you to include _any_ modules. Hence, my ISP recommends hand-rolling your own parsing.

    I’ll look into fixing that now I’ve got full shell access and a proper CGI environment.

  4. Ah, safeperl… I remember that from sable. The habits I learnt from it persisted for ages afterwards… I had to hand-roll my own sorting routines because for some reason safeperl doesn’t allow you to use “sort”… if I had been a computational student I’d have welcomed the chance to optimise the best algorithm… but seeing as I wasn’t it was just a pain! :-)

    David

  5. > One slightly funky thing is that the scripts know how to serve themselves
    > up for download. This means I don’t need to keep two copies on the
    > webserver. It’s very simple (five lines of code) but I’ve not seen it
    > done before.

    Actually, that’s a very old trick. Having a program print its own source code goes way back into the mists of time, certainly at least to the seventies, and combining it with CGI is probably about as old as CGI. The concept of Perl golf often becomes involved as well (see for instance here.) I presume your program opens its own source file for printing. That’s the practical way to do it. (A purist would consider it “cheating”, but creating a quine wasn’t the point of this exercise.)

    I recommend against using CGI::Lite. I’ve had significant, difficult-to-debug problems that turned out to be that module’s fault. When I finally figured out that the module was the problem, it took me less time to roll and debug my own parsing code than I had spent trying to nail down the problem in the first place.