[development] Advice for developing Drupal wiki module

eric Farris eafarris at gmail.com
Tue Jan 10 13:46:21 UTC 2006

On 1/10/06, Steve Dondley <sdondley at gmail.com> wrote:
> > oh, wait, we have that already. :p Really, its possible since a long time.
> Yes, it's true. I've got a wiki on my a site of mine for many months
> without ever seeing Bryght's guide.  But it certainly isn't polished
> or very user friendly.  There's a bg difference between cobbling
> together functionality out of sticks and constructing one solid module
> carefully with bricks and mortar.

Bryght's recipe is great, but we could make this much easier. I think
what we need is a wiki bundle, similar to the ecommerce family of

* something for markup (wiki.module, marksmarty.module, or a rich text
area module like FCKeditor
* something for internode link syntax / node creation (like
freelinking, could be made much richer)
* something for the node itself (like wikipage.module, better perms on
story/page/book, or a CCK content type

But even that's not enough, with current Drupal. If you're looking to
have someone work for pay, have them do something that's actually
*needed*, something that doesn't yet exist. If you want true wikis in
Drupal, the filter system needs some love.

It is impossible (or at least, very difficult) for something like my
freelinking.module to have true wiki capabilities with the current
implementation of filters. Filtering modules need to know more about
what they're working with. One example is having a node know who
authored it, and who authored the existing targets, so that multiple
users could have seperate wikispace within one Drupal site.

Passing the $node to hook_filter would be a step in the right
direction, but as I recall that's been debated before, and I'm not
about to bring that up again... umm, whoops.

Other things we could do that would get us closer to actual wiki functionality:

* Having a node know which other nodes are linking to it
* Turning freelinking.module into an extendable API (see
http://www.eafarris.com/node/959 for my thoughts on this)
* Differentiating between existing and non-existing links at creation
time, without the performance penalty of walking through every
node.title each time
* Fuzzy matching of links

Some of these things are relatively simple patches to
freelinking.module, some of these require more careful thought and


More information about the development mailing list