darkness

OK, so my old web log at http://www.codefu.org/weblogs/darkness/ now points here. RSS feeds redirected appropriately, and I made a little PHP script that redirects archive posts from my old web log to the same entry in my new web log. Please let me know if you find some problem you think I can fix.

I’m back up with my (new) web log. But first, let me share with you what I saw this morning when I went for my breakfast bagel:

I have no idea. (Though I did move the bagels a bit to emphasize the fact that my bagels were found in the blender, and not put there by me - to my knowledge.)

So, anyway. I stopped updating my web log for so long because I didn’t have a good way to enter text. WordPress has all these nice plug-ins for formatted text to HTML, for formats such as Textile and Markdown. However, there is at least one major problem: WordPress doesn’t store the information about what plug-in was used to create a post with the post. In my opinion, plug-ins would ideally be able to do both text to HTML and HTML to text. WordPress would ask the plug-in to convert the content to HTML when you submit a post, and then ask the plug-in to convert back to text when you retrieve a post for editing. Markdown didn’t do this. Textile was straight out because it didn’t seem to have support for hard wrapped lines, a la Emacs, my web log writing tool of choice.

Anyway, what this all means is that I’m using Emacs to convert my posts from Markdown to HTML, and HTML back to Markdown. Aaron Swartz wrote something called html2text which is pretty decent, but doesn’t do hard wrapping of things like lists apparently. It also doesn’t handle some of the more obscure cases of “Markdown markup” in my experience. Thus, I wrote html2markdown. Like html2text, it is written in Python. I’m using it to write my posts now, so it’s going to get some testing from that, plus I tested it against many of the example Markdown markup on the Markdown web pages. You are encouraged to report bugs to me, but please don’t tell me “this HTML input doesn’t produce good Markdown output!” It’s not made to convert general HTML to Markdown, it’s made to convert Markdown-generated HTML to Markdown. Instead, send me a bit of Markdown markup that fails to output something that resembles the input to Markdown.

For posterity, the macros used in my .emacs:

(defun weblog-filter-through-program (program)
  (save-excursion
    (goto-char (point-min))
    (search-forward "nn")
    (shell-command-on-region (point) (point-max) program t t)))
(defun weblog-entry-text-to-html ()
  (interactive)
  (weblog-filter-through-program "text2html"))
(defun weblog-entry-html-to-text ()
  (interactive)
  (weblog-filter-through-program "html2text"))
(defun my-weblog-mode-hook ()
  (local-set-key "C-cbh" 'weblog-entry-text-to-html)
  (local-set-key "C-cbt" 'weblog-entry-html-to-text))

(Also for posterity’s sake, or maybe just mine: Markdown uses four spaces to indicate a pre-formatted block (<pre>). In Emacs, paste in your text, select it as a region, then M-4 C-x TAB.)

This is used in conjunction with mt.el, as described in a previous post. Also, you’ll need to disable automatic paragraphs in WordPress. For some reason, the WordPress developers seem to think that putting this in as an option will needlessly over-complicate WordPress. Whatever the case, using HTML (or, at least, Markdown’s HTML) with WordPress automatic paragraphs will yield things like <p></p> in your pre-formatted text blocks. Dumb. See the suggested plug-in at the top of http://wordpress.org/support/topic.php?id=11097 for my fix. I put this in a file in the appropriate plug-in directory, activated it, and my worries (thus far) are gone. I note that Markdown and Textile plug-ins for WordPress both do roughly the same thing, as they recognize that they don’t need/can’t use WordPress’ automatic paragraphs.

Now I need to link stuff in from my old web log. This post is going to ping the web log services, hopefully. Will post back here if I can manage to find a way to link my old pages to my new web log.

Update: I was going to do this update because I forgot something… but now I forgot what I was going to say. I was distracted because whenever I edited a post (such as this one) from Emacs, the date on the post would get changed to today’s date. Searching around a bit I found the second hunk in http://mycvs.org/wp/wp-content/xmlrpc.12.patch to hold the answer. According to http://ecto.kung-foo.tv/archives/001142.php this might not be neccessary with WP 1.2.2, but the code for current_time('timestamp',1) was still there, rather than strtotime($postdata['post_date']) which uses the original creation time from the post being edited, if a new time isn’t supplied by the client.

I think I remember now. What I was going to say is that html2markdown.py is to be used just like Markdown.pl from the command line. My text2html script is:

Markdown.pl | SmartyPants.pl

And my html2text script is:

SmartyPants.pl --reverse | html2markdown.py

A few things I have noticed about WordPress though. Check out the plugins screen and you may want to enable something like Textile2 or Markdown. If your “Delete Checked Comments” button isn’t working in comments mass edit mode (the first place an MT user goes while deleting all spam comments) check http://wordpress.org/support/3/6170. If your apostrophe looks weird, especially in Konqueror in FC2 for example, I think that’s some sort of font problem. I don’t know how to solve it yet, and I probably won’t bother with trying to figure out how for some time. Make sure you’re not using any software that blocks sending referer: sometimes WordPress checks it and silently fails.

For posting I switched to mt.el. This is a slightly modified version I made to not require my password to be in my .emacs and to change a few places integers were used instead of T and NIL. I recommend you (setq weblog-publish-on-save nil). Otherwise when you weblog-submit-no-publish you’ll publish anyway. Instead use C-c C-p when you don’t want to publish and C-c C-s when you want to publish. I should probably bind C-x C-s to weblog-submit-publish so it works like blogger.el.

I want to install a Wiki under FC1. I tried PhpWiki but I couldn’t get the 1.2.x version running on FC1. Turns out, I think my problem is register_globals = Off in /etc/php.ini per something I found on the PhpWiki Wiki. Then I tried to use 1.3.10 but it apparently has some file_passwd bug which is supposedly fixed in 1.3.11… which isn’t released. I went to go get CVS HEAD, but SourceForge’s CVS servers (only for projects beginning with, like, seven letters, which I’m guessing means that’s how they divide up projects amongst servers and one of their servers pooped out) were down.

So I found MoinMoin instead. MoinMoin runs in Python (cool). MoinMoin doesn’t need and can’t use an RDBMS (not cool, but not exactly uncool either; as long as performance doesn’t suffer, I don’t care).

Of course I want to run it under mod_python. Reading the directions, sounds like mod_python < 3.1.3 had problems. I go the hard route, and decide to install mod_python 3.1.3a (or something like that) from FC2. Kids, don’t make a mistake like I did and get excited when the mod_python RPM from FC2 installs on FC1 without a hitch: it puts files in /usr/lib/python2.3, and FC1’s Python 2.2 obviously doesn’t look there. So, there are a number of routes I could have taken for installing mod_python from FC2 on an FC1 box, at this point:

• I could have futzed with getting that mod_python binary to run under FC1’s python some more. I tried doing something like PythonPath "[ c.replace("2.3", "2.2") for c in sys.path ] + ['/usr/lib/python2.3/site-packages']" in /etc/httpd/conf.d/python.conf but that didn’t fix a damn thing.
• I could get FC2’s Python RPMs and install them. Turns out this would update a number of things like libdb, glibc, and an installation of libselinux. I fear what might happen to something linked against libselinux when it finds it’s a 2.4 kernel with no SELinux. So for now we skip this option in favor of…
• Rebuilding the FC2 mod_python SRPM in FC1. This turned out to be the easiest: rpmbuild --rebuild the SRPM, install, and you’re off and running.

I followed the MoinMoin installation documentation which I had to search around to find. I used something like python setup.py install --home=/srv/www/my.wiki.com --record=install.log to install MoinMoin in my virtual host’s directory. That’s just how I organize things. Checking out install.log it looks like it was nice and didn’t install anything outside of that --home directory. Note: you will need python-devel installed to run setup.py.

I followed the “UNIX as root” instructions on how to make a Wiki instance minus anything that contained the string cgi. You don’t need any of that stuff if you’re using mod_python. I did make /srv/www/my.wiki.com/etc and plunked share/moin/cgi- bin/moin_config.py in it. Edit moin_config.cgi and fill in sitename, data_dir, and url_prefix. In the Apache configuration you will need the Alias directive but not the ScriptAlias directive.

Make sure moin_config.py and pretty much everything else is readable by apache:apache. Especially, check out share/moin/data/text/*, which I think I got bitching about in /var/log/httpd/error_log about at first.

After setting up the instance, I went to the “mod_python Setup using Apache” section. I skipped down to the “Deploying with a fixed mod_python” subsection and followed those instructions. This is my .htaccess which lives in my DocumentRoot:

<Files wiki>
    # Use mod_python as handler
    SetHandler python-program

    # set the path to the MoinMoin package and to the moin_config.py
    PythonPath "['/usr/lib/python2.3/site-packages', '/srv/www/my.wiki.com/lib/python','/srv/www/my.wiki.com/etc']+sys.path"

    # choose the ModPy Request class as handler
    PythonHandler MoinMoin.request::RequestModPy.run
</Files>

Another mistake I made was that I left url_prefix = '/wiki'. This is a problem because in the .htaccess above you’ve said /wiki should go to the mod_python handler, but then you’ve aliased it elsewhere. So I changed my Alias to point at /wikidata and changed url_prefix accordingly. After doing this, one weird problem I had was that links for images that should appear next to InterWiki links weren’t appearing; I was getting their alt text next to the link instead. It looked like they were using the old url_prefix (or logo_string, at least; see moin_config.py to see how logo_string is constructed). I think this had something to do with the byte compiled lib/python/MoinMoin/config.py. I changed config.py a bit to try and debug the problem, reloaded a few things, changed config.py back, and magically everything started working. Since changing config.py meant it was going to get recompiled, I suspect this recompiling fixed the problem I was having.