After spending a couple of days figuring out the drupal module engine, I think I do have a workable version of markdown plugin now ready. It works for me and a few others for now.
Some people have a concern for lock-in into a particular text format. This is because, in drupal, the data is stored in the text format (drupal/textile) and it is processed every time node is viewed. There are good and bad things about this: The good thing being, you are working at a higher level (really?) compared to raw HTML. So all of your modifications will be at that level. The bad thing is the lock-in: i.e. you are commited to markdown or textile format!
There are a couple of ways to counter this. One beauty of markdown is that there exists html2text which converts HTML to text... valid markdown text! But unfortunately
html2txt(markdown(txt)) != txt (it's close but not exact, it can never be)
So maybe we should store the markdown output to the database (instead of text format as now) and run html2txt everytime we want to edit/modify ?
Update: 2005/05/05 Recent versions of drupal already include markdown and textile plugin
2 thoughts on “Drupal Markdown plugin progress…”
More Markdown, please! Any chance you could roll SmartyPants in with it, too?
In fact, wouldn’t it make more sense to look into finding a way to execute a Perl filter as a Drupal module? Because if it could be done, then you never have to worry about losing parity with the real Markdown release… and it IS just a filter after all…
“Some people have a concern for lock-in into a particular text format.”
Kind of a silly concern, because you’re always locked into something… as long as it’s structured you can always convert out of it later if you have to.
So I eventually patched out the filter to add support for SmartyPants-PHP (so it’s like “Markdown with SmartyPants” when using MovableType) and made it a pure filter.
I believe John Gruber said it himself that one of the design points of Markdown was that it would leave existing HTML alone, so why the need to choose? Wiki.module doesn’t make this version-number/on-or-off distinction so why was this in Markdown.module?
It seems like if you really want to specify between HTML or Markdown, it should be an extension of Type (i.e. “HTML/text or PHP” as in some nodes). Don’t you think?
Comments are closed.