i summon one kim

For seven years I’ve maintained a small patch to PHP Markdown Extra. However, the upstream was not happy with it, so I just kept my local copy patched. Now I’ve given in: as Markdown has become very popular, it has been better to just adopt a syntax that works across different implementations (e.g. with GitHub Flavored Markdown). (more…)

I’ve been writing in Markdown for nine years now, because it allows me to spend more time on content as opposed to formatting. Using it with WordPress has required a couple of bug-hunt sessions, but overall I feel it has been a time-saver.

This week I spent a little bit of time experimenting with formatting code snippets. While looking into my earlier writing I realized I’ve had an issue with code snippets repeatedly. Today I took the time to fix the problem by changing the Markdown parser slightly. (more…)

I’ve created a couple of small patches to improve how WordPress works with Markdown:

• markdown-balancetags.diff

  The balanceTags function was preventing the Markdown autotags feature from working by thinking <http://server/page> is actually some sorf of an http tag. I didn’t want to completely disable balanceTags, so I added code to pass through http, https and ftp “tags” untouched.

• markdown-first.diff

  The wptexturize function must be called after Markdown to avoid unwanted “texturizing” of preformatted and code blocks. The fix was easy once I learned that filters have priorities. The default priority is 10, so I modified markdown.php to install itself at priority 8.

I’m beginning to think I should import WordPress to my local CVS repository.

Writing HTML is not exactly easy — all those angle brackets require lots of shift key pressing, and reformatting text from inside one set of tags to outside means working around these or those tags constantly. On the other hand, writing regular plain text email is rather easy. Ascii enhancements to highlight text have been around for ages, and with almost 20 years of writing messages they are practically automatic to my fingers.

With WordPress and other blog tools I’ve looked into different markup systems. I’ve really taken a liking to Markdown, as it is very close to how I write in email. As an added bonus, I can basically take any email and put it on my web server, and it turns into an HTML document almost without any work. And I can still email it as plain text!

Since the framework of this site is written in PHP I installed a PHP version of Markdown. Then I hunted around for a PHP version of SmartyPants for a couple of minutes before realizing I should just look at the WordPress code right under my nose… (Look in the functions-formatting.php file in the distribution.)

To tie it all together, I enhanced my page wrapper to handle .txt files in addition to the .html files it was already processing to add the “look-and-feel” of the site.

I think WordPress needs dedicated filters to be applied on content and excerpt immediately when they are retrieved from the database, to be used by formatting filters such as Markdown.

I like Markdown, but I was having problems with how WordPress does not pass the complete article to it when the “more tag” is used, and when forming RSS descriptions. Markdown uses shorthand link tags that would normally be resolved with references placed at the end of the document. With the truncation, links were not being resolved, and what’s worse, Markdown notation was left in the resulting display.

I created a patch that fixes the problem for my current articles. However, I think multipage entries would still have this problem, so this patch is not sufficient. Also, I’m not sure if I’m causing undesirable side-effects by moving the the_excerpt filter further up in the code.

Before I start working on the filters to be applied on database retrieval, I’m waiting to hear back from WordPress developers about the approach, to avoid wasted work.