Hello there.

I'm a member of the [url=http://www.dreamlyrics.com]DreamLyrics[/url] development team. We're a subscription-funded message gaming site.

The site was setup in a hurry after our CompuServe message gaming site was closed. We rushed a UBB board online overnight, and apart from some small customisation we've been stuck with it ever since.

In the past year we've been toying with the idea of moving to phpBB for the message gaming, and setting up a MediaWiki for our members (so they don't have to setup their own).

That was until one of the team suggested Drupal.

After downloading it and installing it on a test site, here I am. :)

Simply put, we want a site that has a fully featured message board, like phpBB, and a wiki, like MediaWiki.

So far we've been really impressed by the code Drupal is generating. (It must be the only CMS I've ever encountered that isn't stuck in the Nineties.) But our initial assessment has left us, well, intimidated.

It looks like we'd have to create the message board and wiki almost from scratch. The workload we're looking at is beyond our capability to deliver.

That's what it looks like.

My questions then, are thus:

1. Is there an easier way to implement the functionality we need? Custom modules perhaps?

2. Has anyone built a Drupal site along these lines before, and if so, can you link us up?

I realise these are more general questions, but I'm expecting the thread to get technical. ;)

Many thanks.


asbdpl’s picture

The question is, what you want to do, not what tools to use. If you used MediaWiki and phpBB as they are intended to be used (quick editing, hypertexting, threaded discussions...) IMO you won't get lucky with Drupal. However, you didn't explain why you want to leave MediaWiki and phpBB, so I don't have any idea what you're missing in MediaWiki and phpBB or what you're looking for in Drupal.

Wikis: Drupal core doesn't offer any support for the Wikis way. There are a few ongoing projects aiming to include some wiki functionality into Drupal (look for modules "liquidwiki" and "wikitools"); the last time I tried to use them they were far from being useful. What they do does at first sight look similar to a wiki, but it's structures aren't stable. You won't be able to move/redirect pages, you'll get second-rate versioning, no image/media support, and linking tends to break easily. Also, none of this is integrated in other features of Drupal (like forums).

Forums: Drupal offers it's own forums. Their functionality is very limited compared to full-blown forums apps like phpBB, but it's better than a Guestbook. As far as I know, there is no project on the way to significantly extend the capabilities of Drupal's forums, but there are some approaches to *integrate* other forum software more or less in Drupal. Basically that means, that you won't have to manage two different user databases (btw. there is also a MediaWiki/Drupal integration available).

In Drupal, you can get something called "Freelinking" (look for module "freelinking"); basically the same applies here - the node structures become instable - but freelinking is a bit mor ereliable than the wiki toys.

Also, you can replace the input formats in Drupal, meaning you can get rid of the braindead HTML markup (look for "pear wiki filter"); this is a very small subset of MediaWiki markup, but allows some very limited, but fast editing in all areas of Drupal, including Forums.

When ogling with Drupal, also consider (a) that it tends to require lots and lots of horsepower if you have more than a handfull of users, and (b) many features you might need are not in Drupal core but in 3rd party extensions. While the core is tested pretty thoroughly, some modules are not being tested at all. They can damage your Drupal installation, corrupt your database an so on; this is not just a possibility, it happen all the time if you're using lots of modules. Thus, the more extensions you think you'll need, the less Drupal is suitable for you. If you like or need Wikis, you won't get happy with Drupal.

To be on the safe side, use the features in Drupal core and the modules drupal.org is using. If you can live with such an setup, Drupal will be the tool to use.

Regards, -asb

Kocia Łapa’s picture

asb, that's a very well considered reply. We thank you for it.

We haven't actually moved to MediaWiki/phpBB yet, we're still stuck with our ancient UBB only. We were planning a move to phpBB and MediaWiki, but then Drupal was brought up as a CMS that might be able to fill both roles.

From what you're saying it seems like it can't, *but* it may be able to integrate with them (MediaWiki so far, who knows, perhaps phpBB in the future). That's invaluable information and you've probably just saved us a lot of time.

So thank you again. :)

xequae’s picture

I've been using liquid for the wiki on my site and it does have problems, but I've been happy with it haven't had quite the problems you describe. It supports move/redirect pages just fine for me. I've never had a problem with linking breaking. The image/media support is lacking, so I just have to link to the actual image instead of the image node, but hopefully this will be fixed eventually. Also templates would be a nice addition. Also it supports hierarchical wiki IDs, which I have found to be very cool.

This isn't as nice as Media wiki, but it is a good start and if you are interested in putting in some development time, I think a lot of the issues could be dealt with fairly easily.


asbdpl’s picture

I haven't used LiquidWiki in Drupal 5.x, so probably there were some sginificant improvements recently; when I tried to use it in Drupal 4.7 a few months ago, it proved to be completely useless due to loads of critical bugs.

After this ugly experience, I switched to Wikitools/Freelinking in combination with PEAR MediaWiki Input format, recent_changes and diff modules. This setup worked far better but still had too many critical bugs. If xequae.com is the site you're referring to, at least one major difference appears: I tried to _integrate_ the wiki completely in the site, not running a separate "structure" under /wiki (however, that's exactly what I'm doing currently with Drupal & Mediawiki ;)

Currently, I got rid completely of LiquidWiki and Wikitools, but am still using the PEAR input format (all over the site!), and the recent_changes and diff modules. Separately Gallery2 and MediaWiki are installed; user authentication basically can be done by drupal as "master" with the modules "Gallery", and "AuthDrupal", but this doesn't work yet reliable with *both* integrated at the same time.

Most useful rendered the "PEAR Wiki filter" input format, which significantly speeds up authoring and editing pages, working with Drupal sometimes feels almost as good as working with MediaWiki. However, there are still lots of restrictions (very limited set of markup, no support for tables or images), and I still haven't found any useful solution for linking nodes - except hardcoding them as [http://example.com external Links] (which of course break if a node is renamed).

Anyway, if I had the chance to set up a site from scratch, I'd prefer MediaWiki to any Drupal-Wiki-workaround. Currently, I don't have the option, since my Drupal sites contain > 30k nodes ;) However, it always depends on what you're trying to accomplish,

Greetings, -asb

http://www.cinedat.org/ | http://www.encycan.de/ | http://www.kefk.org/

sepeck’s picture

As to the 'wiki' way, it depends on what aspects of a wiki a group is going for.

There are wiki syntax filters for whom that is important. The issue with those is, Drupal does not modify submitted content so if you don't 'need' wiki syntax and stick with HTML input then long term your content is easier to maintain. on the other hand, filters are not all that difficult to migrate versions.

The freelinking thing you mention is ok if you need freelinking. If you use the book module you get automatic hierarchy and menu building with built in next/previous linking on each node. You can also easily move things around with the built in Outline feature that comes with book module.

If you mean user editable content with revisions as your meaning of wiki, then that is certainly possible and easy with Drupal. Especially combined with the DIFF module and permissions. Create a content type, set permissions, turn on default revisions for it, add diff module, set permissions for users to view revisions, done.

By use a lot of horse power... that's not entirely accurate. It really depends on your needs. If you are expecting thousands of hits a day, then dedicated server may come in handy but there are tens of thousands of small sites on shared hosting. I run 15 sites on one 1 GHz with 2MB of Ram server just fine.

I dispute your conclusions about contrib modules. Can things go wrong? Sure, not very likely. Just avoid the contributed category module and use the built in taxonomy module. The contrib Category module is for advanced special use cases. Drupal is built around the concept of using contrib modules. It's built to have a core base and then you add what you need to craft the functionality of your site to your groups needs. It helps that with CCK extensions and Views modules that they significantly reduce the need to make your own custom modules while still elaving you with the option to do so.

While Drupal is not media wiki (whew) it sounds like Drupal will more then adequately do what the requester wants. Integrate all sites content into one CMS that integrates user accounts, features and content into one searchable whole.

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

asbdpl’s picture

Hi Steven,

I don't think, that it would make sense to discuss hat a Wiki is; what is supposed to be a Wiki is quite commonly accepted; if you strip essential features from it, it isn't a Wiki anymore but some kind of community site with loosened access permissions. With Drupal, you can build such a community site, which is - like a Blog - mainly structured by date of the node's creation, where users are able to contribute and, to some degree, edit other user's content.

The main features of a Wiki are similar, but the focus is completely different. A community portal helps to *announce* things and maybe to discuss about the news items; it is bound to the chronology, and especially Drupal is not very good, to say it friendly, at presenting non-chronological content. A Wiki is intended to help working on topics, especially on texts, together. Most Wiki engines, including MediaWiki, are pretty poor when it comes to supporting (threaded, structured) discussions. Drupal has it's own forum subsystem, but as far as I know, forum discussions can't be attached to, let's say, a story node.

A Wiki is a full-blown hypertext system, Drupal is not. A Wiki makes hyperlinking simple, fast, and reliable. Drupal is quite the opposite. A Wiki takes care, that at least internal hyperlinks can't break; Drupal doesn't give a sh*t about broken hyperlinks. A Wiki makes creating a new page as simple and fast as possible; in Drupal, creating new pages requires several clicks and usually decisions about node types, which require knowledge and understanding about the features of different node types. A Wiki makes editing an existing page simple ("just a click away"), in Drupal it isn't, at least not without additional 3rd party filters. A wiki provides sematic URLs, links are page titles, page titles can be used to link to a page; Drupal uses by default the stupidest way of naming nodes: numbers without any semantic meaning; again, 3rd party modules fix this, but it's still not in Drupal core. A Wiki helps keeping track of versions and edit histories, Drupal core can't provide this functionality (3rd party modules can, to some degree, help with this). Modern Wiki engines like MediaWiki support a wide range of media, including images, sounds, and videos; Drupal core doesn't even support images, only 3rd party modules do that. If you use alternative input formats like the PEAR Wiki filter, you loose practically any support for images and "fancy" stuff like tables. A Wiki is as simple as possible, Drupal isn't (yes, MediaWiki as well isn't simple anymore, if you try to use advanced features like entering heroglyphs or mathematical formulae). The usage of a Wiki is simple to learn, most new users don't understand even the basics of Drupal. Modern Wiki engines help making the existing content accessible in many ways (e.g. tools to locate uncategorized pages), and help administrating the data (scripts in /maintenance directory) - Drupal has *serious* deficits in this area (I just lost thousands of nodes and any non-7bit characters because of this).

Again, I don't have a problem with 3rd party extensions in general - if there is at least some procedure to avoid dangerous modules; but I have a problem, if 3rd party modules are damaging the database beyond repair - as happened with the "categories" module, which - even weeks after uninstalling it - damaged the database; the only and "recommended" solution from drupal.org was to *delete* all forums, including it's content, and to recreate them. Stuff like this shouldn't happen and wouldn't happen, if there would be some basic quality assurance for modules. Currently, there is still no QA for 3rd party modules, so I recommend not using them, if possible.

Also, I dislike the current development model of Drupal which is already preparing Drupal 7 but doesn't care about releasing maintenance releases even for Drupal 5.1, let alone even older versions. Drupal 5.1 contains serious bugs, e.g. the book module is broken, which is known for months, and fixes are available - even performance fixes do exist - but no bugfix release is being published. If you would set up a new Drupal site today, you would have to install lots of patches which are spread all over drupal.org. Stuff like this doesn't build trust by the users.

> By use a lot of horse power... that's not entirely accurate. It really
> depends on your needs. If you are expecting thousands
> of hits a day, then dedicated server may come in handy but there
> are tens of thousands of small sites on shared hosting.
> I run 15 sites on one 1 GHz with 2MB of Ram server just fine.

I assume, you mean 2 *Gigabytes* of RAM? That's what I mean by "horsepower". Dedicated servers like this start at about EUR 100/month, that's a lot of cash for a hobby.

I started to run Drupal a few years ago on a dedicated server with an Intel Celeron and 512 MB RAM which costed around EUR 40/month; it was *impossible* to run a Drupal site on this server, and definitely there weren't many concurrent users. I got average loading times of 2 minutes per page, and saving times around 2-4 minutes per page (btw: MediaWiki ran fine in this setup). It got better by removing most of the 3rd party modules, which led to a very limited set of features; e.g., I couldn't allow tracksback, since trackback spam forces the use of spam filtering; the load of the spam module killed the server several times a day - until I disabled spam filtering and trackbacks. After removing most of the 3rd party modules, I got average loading times of one minutes per page, and saving times around 1-2 minutes per page. I didn't get many recurring users as you might imagine. As long as the contract ran, this server ran 24/7 close to 100% CPU load. Things got better when I rented a dedicated server with AMD opteron dual core CPU and 2 GB of RAM, but it costs a *lot* of money. Other systems *do* run equally fast on a lot cheaper hardware.

Also I would like to recall, that many users trying to run Drupal on virtual servers or in shared hosting environments get kicked out due to high system load; the forums at drupal.org are full of such reports; also, even drupal.org - which definitely runs on hardware with lots of horsepower -, had and still has performance problem, it was even on the front page a few weeks ago. Saving my first message a few hours ago took approx. 2 minutes, saving the last message took already over 4 minutes.

Greetings, -asb

sepeck’s picture

I don't think, that it would make sense to discuss hat a Wiki is; what is supposed to be a Wiki is quite commonly accepted;

I disagree. People say wiki as shorthand, but over time I have found that yes, some people wanted the 'full wiki' experience, while others only wanted and thought of wiki's as user editable pages with revision control and some thought it meant the weird wiki markup syntax.

In the past year we've been toying with the idea of moving to phpBB for the message gaming, and setting up a MediaWiki for our members (so they don't have to setup their own).

The originators request was, they are thinking of setting up a site for their members to put stuff up. They mentioned MediaWiki. At this point it is unclear they want/need a wiki. It is clear they want/need a site to place content.

If they don't have a requirement to use a wiki, then Drupal offers an avenue to have a site where all their content is integrated and search-able with central user registration. It also gives a solid base on which to expand their site in the future. For instance, what if they decide they'd like a newsletter? Well SimpleNews works fairly well and it's content integrates with Drupal.

If they want a wiki, then what elements or features of a wiki then becomes important. That's why you can never assume that someone actually wants a wiki. They may just want some of the features of a wiki and depending on what they are, Drupal may be a much better fit.

Drupal performance a few years ago was not as good as it is now. Despite many contrib modules being written by Drupal or php neophytes, most are also much better in general. There is loads more room for improvements but with CCK and Views ad ons, the need to have lots of add ons is often significantly reduced.

The requester didn't actually mention the size of their environment so an instant assumption that your experience directly maps to theirs and that Drupal wouldn't perform well.

Comparing Drupal.org's performance is not even in the same field. Until two years ago, Drupal.org ran on one server that hosted multiple sites other then drupal.org. It was at around 80,000 users before a new solution had to be reached. Currently several thousand unique authenticated visitors per month and several million unique page views a month, several terabytes of traffic a month. The database server was a little pounded. Also in the last several weeks we have significantly changed the architecture so a few configuration issues have cropped up.

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain

-Steven Peck
Test site, always start with a test site.
Drupal Best Practices Guide

asbdpl’s picture

You're absolutely right; if the original poster doesn't give any details about what he tries to accomplish, this discussion is leading nowhere.