Perhaps it may shock some of you that I actually keep quite busy. In fact, over the weekend we took a trip to Pittsburgh to visit Berta’s sister and their new baby, Ethen. (“e”?) So I have not had time to fully unpack my office.
There are about 8 packing boxes of books that are going onto my office as soon as I finish hooking up the actual computer equipment. This will involve drilling some holes, since the cabinets have an outlet inside them (this is where the computers will go), but the shelves have no power nearby to accomodate the printer, scanner, mixer, synthesizer, etc.
Nevertheless, one might wonder what I’ve been up to development-wise for all this time, especially if I have had some little access to a PC. After all, I haven’t produced a line of WordPress code in ages, plugin or otherwise. Really, I’m not really sure what to do with WordPress these days. Sometimes I feel like I should do more with it, sometimes I feel like I want to have nothing to do with it, and sometimes I wonder what more really needs to be done with it. And so I put that off for another day.
Instead, I’ve been working a lot with MicroWiki. There hasn’t been a lot of noise on that front, either. And while the reports of things not working pile up in the support forums (yes, I read them, even if I don’t say anything), I’m still churning away.
What I’ve been doing lately with MicroWiki is moving non-essential functionality into plugins. The plugins will all be part of the package, but they won’t be essential to the system. I discovered that I was adding new functionality to accomodate certain needs, and that this functionality wasn’t necessarily of interest to the software’s primary audience. And so these features are pluggable.
But what are they? I’m glad you asked…
One of the first things I added was basic blogging capability. Why would I do this if I already use WordPress? Well, a few of my other sites use MicroWiki (and don’t already use WordPress), and I’d rather not dump 2MB of new code, a new admin system, and a new database on them just to add a little blog. So the blog plugin was born.
Basically, to create new blog entries you just create new subpages under a specific page. So for example, you would create “/blog/My+New+Post” to create a new post. The page “/blog” would contain a single wiki macro that says “subpages of ‘/blog’ are blog entries, display them here in a certain format”. And it does.
This is also neat because the macro lets you point to some other page as the source of the blog entries. So you can easily put more than one “blog” on a single page, and style them differently (using the built-in formatting features) than how they appear alsewhere.
You can use this same macro to build a feed for your blogs by using a different format to output the pages. There are several pages that come with the plugin that enable this, and do it via a new “RSS” namespace. So you have your blog at “/blog” and the RSS version is at “/RSS:blog”. Very tidy.
I have also added some caching capability to the wiki, without which the blog would be completely unmanageable. Since it renders each blog entry as a fully-formatted page, a blog page can consume a good bit of processor time. With the cache, everything loads quickly and updates when any of its dependencies are updated. The cache functionality is available to any core feature or plugin, and I may make even more use of it with other features.
A separate plugin enables technorati tags in wiki pages. You just add a macro to create the appropriate tags in the RSS output. I will soon add a feature to ping Technorati when these changes are accepted.
The only significant thing lacking with the blog feature right now is commenting. And that shouldn’t be too difficult. The wiki already supports quite a bit of submission and posting functionality. It should be pretty trivial to create a macro that updates a page in the “comment” namespace with new comments as they come in.
Now that you have blog functionality available, you might want to add that “enable blog on wiki” to your to-do list. Well, MicroWiki makes that easier with the new to-do list plugin.
You can see the to-do list in action. Basically, you add the to-do macro to a page, and that enables the dynamic to-do list functionality on that page. You can add and rearrange to-do items just like on sites like Ta-da Lists. If you put more than one to-do macro on a page, you can drag items between the lists.
I thought I was pretty much done, but it seems there is still a small quirk that I need to work out. You should be able to put a to-do list on a page and then include that whole page inside another page and still have the list work. This would let you put a to-do in the sidebar and have access to it throughout your wiki. You could then move to-do items from any page into the list in the sidebar, then switch pages, and move it from the sidebar onto the new page. I should have that one figured out very soon.
I’ve been beefing up the image gallery functionality of the wiki, too. The wiki has always had image handling capabilities that (in my not-so-humble opinion) dwarfed image handling in other wikis. I have removed that functionality from the core software and made a plugin of it.
The updated gallery displays all of the images from within one of the gallery directories as thumbnails. You simply put a gallery macro on a wiki page, specify the gallery name (the directory with the images in it) and optionally the size of the thumbnails. MicroWiki uses lightbox to help navigate through the gallery pages. When you click on an image, it pops up in an animated way, and an information bar appears at the top. When you click on the details link in the info bar, some custom code uses ajax to fetch the wiki page for the image and display it.
Did I mention before that every image handled by MicroWiki gets its own page? You can style that page using whatever regular wiki code you want to provide details about the image.
I updated the default layout of the wiki since the last release, but I haven’t added the new default image uploading functionality. I’m thinking that I will rip this out of the core code and make a plugin of it, too. After I’m done removing all the extra stuff, MicroWiki will be extra-svelte.
One thing in particular I need to do is move the form-handling and wizard functionaltiy into its own plugin. I wrote that stuff specifically for one site and haven’t used it for anything since. It’s a huge chunk of MicroWiki’s code, and if nobody uses it then there’s no good reason to include it in the source on every page load.
I also need to extend the plugin capabilities to more easily enable action overrides. So from a plugin you would be able to add new actions to a page, or override the existing functionality of an action. A couple examples include a plugin that displays page change histories differently, or displays a visual diff between two versions of the same page. (Note that this functionality is already in MicroWiki to some extent if you use the built-in RSS update feeds.)
Another thing I’ve added is the ability to use the subdomain of a site as part of the configuration details. So you can select the database to use for MicroWiki based on the subdomain that was requested. The bottom line - you can set up completely separate wikis on different subdomains using only one copy of the software. I have set up such a system for my own testing purposes, and may be convinced to give interested testers an account.
I’m still trying to work through some bugs, especially the escaped quotes issues. I just don’t have a server configured in a way that has that problem, which makes it difficult to debug. Maybe I’ll tweak a local Apache configuration to emulate the buggy behavior.
So that’s the productivity. That and the unpacking and the visiting inlaws and the getting the washing machine installed. Speaking of which, I should probably call them…
