Ladies and gentlemen, I present to you my first WordPress plugin — [[http://floatingsun.net/blog/code/wp-dokuwiki|WP-Dokuwiki]]!!

I have fixed a couple of important bugs (related to the path names) since the announcement. So make sure you are using the latest tarball!

Ever since I moved to this new blog, I have been writing my posts in the excellent [[http://wiki.splitbrain.org/wiki:syntax|Dokuwiki markup]] enabled by the [[https://granny.homelinux.org/CryForHelp/?page_id=199|Dokuwiki markup plugin]] (that plugin is also currently [[http://dev.wp-plugins.org/browser/dokuwiki-markup/|hosted on wp-plugins.org]]). The plugin was working very well for me, so why did I write my own you ask? Well couple of reasons actually:

* A while back, I discovered a severe bug in the plugin — it leaves a hanging unclosed tag in the generated content. Forget about balanced code, this is not even valid HTML! Trying to be a good user, I quickly [[http://dev.wp-plugins.org/ticket/249|reported the bug]], and even submitted a patch to fix it. That was almost 6 months back. The patch has not been applied, and the plugin remains buggy. Of course I was using a fixed version locally.
* In the meantime, a new version of [[http://wiki.splitbrain.org/wiki:dokuwiki|Dokuwiki]] was released. Apart from syntactical goodness and new features, this release had a very important feature — a //vastly// improved architecture. You have to look at the code to see what I mean, but just looking at the [[http://wiki.splitbrain.org/wiki:parser|through documentation on the parser]] will give you some idea of what I mean. Infact, of all the wiki’s I’ve used, Dokuwiki has been by far the most impressive and robust. I really like the neat architecture of the lexer, parser and the hooks for the plugins. It makes writing plugins for building your own syntax really easy (take a look at [[http://wiki.splitbrain.org/wiki%3Aplugins|some of the available plugins]]). I was craving to use this new code for the markup plugin, instead of the earlier code. But dokuwiki-markup was not being maintained/developed, so I could not wait anymore.
* In constructing this plugin, I have tried to make minimal changes to the original dokuwiki code. In fact, I only had to modify **5 lines in ONE file** in the original dokuwiki code. Of course I removed a lot of files from the distribution that I didn’t need to make the plugin — I basically retained the parser and threw away everything else. And then I just wrote a wrapper around it that would invoked the parser and render the formatted text. The nice thing now is that when a new version of Dokuwiki comes out, I have to make minimal changes to make it work with my plugin.
* dokuwiki-markup requires manual configuration for installation — make symlinks to certain directories, copy over CSS rules by hand etc. WP-Dokuwiki on the other hand provides complete automated install — no extra manual configuration required!

I don’t mean to bash on dokuwiki-markup — its a great plugin, one that introduced me to Dokuwiki in the first place, and for that I’m grateful. However, I do believe WP-Dokuwiki is a much better plugin, and since I’m eating my own dog food here (this site runs on WP-Dokuwiki), you can be sure I’ll keep it updated :-)

So give it a shot. Details on the plugin features, syntax support, and installation information can be found on the [[http://floatingsun.net/blog/code/wp-dokuwiki|WP-Dokuwiki]] page.


  1. she

    DOKU_BASE url isn’t correct.

    file url

    32 line

    if(!defined(‘DOKU_BASE’)) define(‘DOKU_BASE’,getBaseURL(true) . ‘wp-content/plugins/dokuwiki/’);

    must be below
    if(!defined(‘DOKU_BASE’)) define(‘DOKU_BASE’,getBaseURL(true) . ‘wp-content/plugins/wp-dokuwiki/’);

  2. diwaker

    @she: which br tag? If you look at the source for this page, you should see the dokuwiki generated code within special comments — atleast for me there are no extra br’s being generated.

  3. Pingback: aoiro-blog » links for 2006-02-06

Leave a Reply