What are the main advantages of DokuWiki in this scenario?

Of all the tasks around a website, specially if the content tends to be static, the major one of all is the content editing task. The content editor must know HTML/XHTML + CSS and sometimes even PHP, in order to present the content and link the internal pages in the a that suits the site needs. The WikiWay of content editing is excellent to minimize the burden of this task:

• No need to know HTML/XHTML, CSS or PHP - not if the content editor focuses

What features does DokuWiki lack to “compete” against simple, practical and easy-to-use CMS systems?

A powerful and yet simple template mechanism, which allows themes to be easily produced.

Why use DokuWiki to drive a normal website, instead of one of the well-known Content Management Systems?

Besides offering pratical ways of content-editing, a simple yet powerful syntax, DokuWiki also looks nice and has a small code footprint (around 1 MB), which makes it fast to upload to a remote site. The question should be: why not use DokuWiki to power a website?

When is DokuWiki not practical to use in a specific website profile?

• When the content is relational: for example, e-commerce sites that have products may that belong to several categories and several options associated with some of the products.
• When the workflow of a business process is not trivial: for example, when checking out a shopping cart through an online transaction.

The plan was to replace (and completely re-write since the focus of the site has changed) a rather large content-based website with something much easier to manage. The site is about software preservation, documenting our progress, technical achievements and about the subject area. Using a Wiki to manage the site did not immediately come to mind, especially since the content would always be uneditable by the public anyway.

The current site was written in (non-compliant) HTML4 and had various problems, such as:

1. Any change to the layout meant many many files need to be changed. This was fine for the original designer, since they owned a (probably quite old) copy of Dreamweaver that did it automatically, but since they have departed, it falls on several other people to maintain the site who have no (and no wish to use) any visual website development tools.
2. Standards compliance. Currently, the site code is really rather abysmal (not surprising - generated code, from an old tool). Then plan is to make it completely XHTML compliance, and a completely table-less layout.
3. A lot of the HTML is bloated, by using CSS with can probably strip nearly 1/4 of the page size off.
4. Any editor of the content requires HTML knowledge and access to the website FTP and/or database. Being an international project, we have pages in multiple languages. So we get submissions of text-file translations which we have to work back into HTML to go back in.

Although the following “journalized” content is very good, the website seems to be more of a collaborative-documentation nature (many-to-many) than a regular product-showcase or company-presentation nature (one-to-many). In this scenario, DokuWiki is really excellent. But how adequate would it be to handle/manage sites with content targetted to be more “viewed” than “edited”? — Straider 2005-02-17 21:01

Well, I personally write most of the documentation, and once a page is done, it doesn't change that much, just corrections more than anything, and linking bits together. Certainly viewed a great deal more than it is edited. The translations are certainly collaborative though. But I guess there is slightly more to it than a “classic” website. If you feel this doesn't apply, feel free to delete all this. :)

Please, don't get me wrong. I see this document as a very worthy document (with valuable information). The point I was trying to make across is that usually people tend to go after a nice-looking and visually-complicated layout rather than focus on the content itself. But as one can see, most of the examples posted in DokuWiki's user list are of collaborative nature. And I'd like to see more of other examples, if they do exist. My assumption is that people who build these kinda of sites would take DokuWiki, change the layout (maybe just through the include hooks mechanism) and present the “corporate-content” site without much effort in the bells'n'whistles of visually heavy loaded sites. In any case, this document is valuable, I see no reasons to propose it for removal. I hope everyone else agrees. ;) — Straider 2005-02-18 12:20

To solve the first three problems, a new website was developed which uses PHP to help dynamically generate a lot of the layout from various template files. As targeted, this is complete XHTML/CSS. At this point, point 4 had not really been addressed, and there wasn't much awareness of the “wiki-way”, and everything (apart from browser detection) is hand-written. It was generally assumed we would have some kind of submission system, where people would be submitting documents online to be incorporated by the web admin.

Pretty much all of the “static” (content that does not change over time, like work-in-progress reports) content has been moved over to XHTML (using PHP helper macros to display links, images, etc.).

The only thing left to do is the Knowledge Base. This one is a more complicated problem, because the content changes quite regularly, and is updated by multiple people, some of whom we may not know very well (like for translations to other languages), and therefore we may not want to grant access to the website in general. Not only that, the knowledge base is currently stored in a database, accessed via custom scripts, and although that gives us some kind of page generation, it is very annoying to do updates.

After being stuck on the knowledge base problem for a while, we started experimenting with Wiki's. As long as we can enforce appropriate authorisation to editors of pages, this was almost exactly what we were looking for. We decided early on that it would have to be PHP based, since that is what was available on our host, and what we had experience of.

First we tried PhpWiki, which was nice and fast (something we were really looking for) but we found it hard to integrate into our new XHTML site, and was requiring lots of effort to get it looking nice.

Next, we tried TikiWiki. We were very impressed with its template/macro language, which would really help integration, and there were plenty of other features that we could slowly bring into making the experience of our site better. Initially, we also liked the fact that we could configure the whole thing through a web interface. However, after trying to actually configure it, that is, trying to find options hidden away in the UI, it started to become a bit of a chore. The deciding factor however was when we started putting up a few test pages… On our host, it was slow. Even with most “extra features” turned off, we were still getting 50+ database queries, and several seconds for each page to appear.

Next, we (almost) tried MediaWiki. The support for different languages was the main attraction. However the homepage did not really impress us much, I hate to judge a book by its cover, but, well… We assumed this would be the default look of the Wiki, and it would take a large amount of effort on our part to do what we wanted with it. Not only that, but we found it very difficult to find such things as a feature list on the site, so we gave up looking.

Next we tried DokuWiki, and initial impressions were very good. It was attractive and lean. The code was very sensibly layed out, so we could see that it would be very simple to adapt it to our needs should we need to. Writing content in several languages is one issue, but we decided we could either simply add that feature, or add them as normal Wiki pages.

Some changes are probably needed to the DokuWiki code to fit in with our new site styling. Our current site is very content-focused, so the navigation is done at the top of the page rather than waste space on a side-bar. So, we have two choices here, we can either “embed” the wiki part into the content area of our new site, or we can implement our new site template into DokuWiki, “the proper way” I guess. Not sure which we are going to do right now, it is very likely we will want to write new (and not just knowledge base) pages in wiki-syntax, so expanding our use of DokuWiki into more of the site is quite likely. However, we will always have pages which are not appropriate for the wiki part, like the more PHP-heavy pages, such as:

• The sortable/searchable list of software artifacts preserved (very basically, disk images), which number in the 1000's and are stored in a database.
• Our collection of physical software artifacts
• Our publically-disclosed accounting system.

I guess we will have to think about that.

Some changes were also needed to try to make it less “wiki-ish”. So far this has been simply to remove underscores from some of the links (thanks to the Tips and Tricks page!), and give some title-case. We may later remove various things like the Show Page Source button, since they are not really helpful for the casual site visitor.

So far, the experience with DokuWiki is great, because if we want to change something, it is very easy to find where to do it.

I've been using DokuWiki for some time for internal and developer documentation, wishing I could use it to manage my public static web site. After looking through the code and coming to the conclusion that what I was trying was far enough outside the normal use case that the features I'd need were unlikely to be added, I wrote a tool to do it for me. This tool spiders my wiki site via SSL and creates a static HTML version of the site, creating a mapping of the wiki namespace into the html directory structure. The stylesheets are preserved, all URLs are rewritten, including image URLs which are changed to normal image tags. All buttons not relevant to static use are removed from the pages. It also rebases the URLs from a dokuwiki subdirectory at the source server to the root of the public server. The website this can be seen at is http://www.vscape.com, and I'll be releasing this code as open source in the near future when I clean the output up a little more, although if someone wants it sooner they can email me: kerry@vscape.com