Installing DokuWiki is easy - in general it's just unpacking and setting permissions. However a detailed description for various scenarios is given here.
The first step is the same for everyone: Download the newest release from the Download Page 1).
Note: Windows-Users may need to rename the file from dokuwiki-YYYY-MM-DD.tgz
to dokuwiki-YYYY-MM-DD.tar.gz
to make their archive tool recognize the file format correctly (See 209). For Windows and other platforms, free Ultimate Zip. It worked fine for me in unpacking dokuwiki.tgz on Windows
After you have followed the basic instructions, your DokuWiki has out of the box behaviour:
This is the common scenario for installing DokuWiki in a corporate environment or on your own rootserver.
#> cd /var/www/ #> tar -xzvf /path/to/downloaded/dokuwiki-YYYY-MM-DD.tgz
#> mv dokuwiki-YYYY-MM-DD dokuwiki
#> touch dokuwiki/data/changes.log
nobody
, www-data
or apache
#> chown -R nobody dokuwiki/data
dokuwiki/conf/dokuwiki.php
(see config) if you want to change anything within it. Better yet, create dokuwiki/conf/local.php
containing those lines from dokuwiki.php
which you want to change. This way, your changes are preserved when overwriting the dokuwiki.php
with a new release.check
option in a URL and pull it up into a browser:–
Occasionally chowning can be no good at all, I couldn't chown files to another user on a server i was using, instead i chmodded my data dir. also the Options Specified in .htaccess can sometimes cause an error. rename or delete the .htaccess file and the error will solve itself.
NanoWeb is a PHP-based web server, and much lighter in its memory footprint than something like Apache. Nagios and Double Choco Latte both work fine, as does DokuWiki.
However, after following the instructions as described above for use with the Apache web server, it will be necessary to modify dokuwiki.php, as it does not automatically detect its web server location (URL).
Autodetection of an URL is not possible in all thinkable environments. Especially not when extensive URL rewriting and other forwarding mechnisms are in use. Furthermore the word “relative dir” is a bit missleading. Because dokuwiki requires an absolute pathname here. So start with a slash and end with a slash as in the example below. – Doogie - 27. May 2005
Change the line:
$conf['basedir'] = ''; //relative dir to serveroot - blank for autodetection
to something like:
$conf['basedir'] = '/dokuwiki/'; //relative dir to serveroot - blank for autodetection
Note that, for whatever reason, a trailing slash is required!!
See the detailed HOWTO for DokuWiki on Tiger.
The HOWTO does not appear to be up-to-date (though it was helpful).
Below is what I did for Tiger (no previous DokuWiki installed):
$ cd ~/Desktop && tar -zxvf dokuwiki-2005-07-13.tgz $ mv dokuwiki-2005-07-13 ~/Sites/dokuwiki $ cd ~/Sites/dokuwiki $ touch data/changes.log $ sudo chown -R www data
$conf['basedir'] = '/~user/dokuwiki/';
in conf/local.php; autodetection does not work!
Official Debian Packages, provided by Matti Pöllä, can be fetched with apt from the testing and unstable sections. Homepage for this .deb is http://packages.debian.org/unstable/web/dokuwiki. To install DokuWiki, use the standard Debian procedure:
#> apt-get update #> apt-get install dokuwiki
The package is unpacked, debconf asks a few questions, and it is set up. Invoke dokuwiki through your browser. For example, if you said the web-accessible location should be /dokuwiki, and access should be by localhost only, http://localhost/dokuwiki will bring up the start page.
Use the Debian bug tracking system to report any bugs with the package http://www.debian.org/Bugs/
– Where does debian put the data dirs?
– This might help to locate the data directories.
To install dokuwiki using the FreeBSD ports tree, do the following:
#> cd /usr/ports/www/dokuwiki #> make install clean
The default DokuWiki directory is /usr/local/www/data/dokuwiki
– Of course the directory can be changed or symbolic linked to anywhere
To upgrade using the ports tree, do:
#> portupgrade dokuwiki
Make sure that the ports tree has been updated, or this will have no effect.
This is for people who want to use DokuWiki on their Desktop-Machine
dokuwiki-YYYY-MM-DD
directory to somewhere below your new webserver documentroot eg. c:\xampp\htdocs\
and rename it to dokuwiki
dokuwiki/data/
directory create a new empty file named changes.log
(rightclick and select new → Textfile, then rename the file)dokuwiki.php
file in the conf
directory to configure your Wiki (see config) or (better) create a new conf/local.php
file containing those lines from dokuwiki.php
, which you want to change. This way your changes are preserved when overwriting the dokuwiki.php
with a new release.Sometimes, you might require to create a attic/ directory under data dir. Thanks to oak to help me out with this.
In the last version (2005-07-01) you have to create those directories too : data/cache, data/meta, data/locks.
This is for people who want to use DokuWiki on a Windows machine with IIS webserver (Windows 2000, Windows XP or Windows Server 2003)
dokuwiki-YYYY-MM-DD
directory to dokuwiki
and move it toc:\inetpub\dokuwiki
dokuwiki/data/
directory create a new empty file named changes.log
, and create the folders attic/, meta/, locks/ and cache/dokuwiki.php
file in the conf
directory to configure your Wiki (see config) or (better) create a new conf/local.php
file containing those lines from dokuwiki.php
, which you want to change. This way your changes are preserved when overwriting the dokuwiki.php
with a new release.This applies to most users of rented webspace.
A Screencast for this type of installation is available, too.
dokuwiki-YYYY-MM-DD/data
directory create a new empty file named changes.log
dokuwiki.php
file in the conf
directory to configure your Wiki (see config) or (better) create a new conf/local.php
file containing those lines from dokuwiki.php
, which you want to change. This way your changes are preserved when overwriting the dokuwiki.php
with a new release.data
: attic, cache, locks, meta (media?)dokuwiki-YYYY-MM-DD
directory to your webhost using your favourite FTP-toolcheck
option like this: http://www.example.com/dokuwiki/doku.php?do=checkchmod
and is sometimes hidden somewhere in the menubar or can be accessed via right clickrwxrwxrwx
or 777 for the dokuwiki/data/
directory and all files and directories below.rwxrwx---
or 770 first – it is more secure but for most webhosters this will not work.You can also check out the newest development version using darcs.
Before upgrading, you should always read the changelog to see if something changed you should be aware of when upgrading. To determine the version you are running, have a look in the HTML source of a Page generated by DokuWiki there should be something like <meta name=“generator” content=“DokuWiki 2005-02-06” />
4).
Some reminders! I tried to upgrade from 2005-05-17 to 2005-07-13, and had problems with plain ACL. This has been discussed at http://wiki.splitbrain.org/wiki:discussion:acl?s=users%5C.auth#user_registration_-_can_t_register . I was in the process of reverted to 2005-05-13, and decided to give another try, which appears to have been successful. Two hints: (a) when transferring files over to the updated program directory, make sure that the chmod is set to 777 for all of them, or they won't be editable!; and (b) when updating configuration files, remember to use a UTF-8 editor if you're on Windows! (I use Crimson Editor). {David Ing, 2005/07/17}
The easiest way to upgrade is perform the following steps
changes.log
and the contents of your data/
(perhaps not the wiki/
directory), attic/
and media/
directories from the backup location to the new install dir changes.log
(which was in the root directory) is now in the data/
directory;data/
directory is now in the data/pages/
directory; andattic/
and media/
directories that were in the root directory are now under the data/
directory.conf/local.php
from the backup location to the new install diruser.auth
into user.auth.php
and acl.auth
into acl.auth.php
. If you're using Windows, remember to use an editor that saves in UTF-8 Unix format, such as Crimson Editor.If you have made any changes on interwiki or smiley configurations or the source code itself, you will probably want to reapply them after upgrading.
When you upgrade from a version prior to 2005-02-06, you will need to convert your data to UTF8 after upgrading.
If you encounter some inconsistencies in DokuWikis behaviour after upgrading, you should delete the cache files in data/.cache/
and media/.cache/
. You should make sure your browser hasn't cached an old stylesheet, too.
This method is not official - i (redeeman, visitor) just thought it would be nice to present this method of upgrade, which i just have used myself to upgrade from 2005-07-01 to 2005-07-13.
the thing i do, is to use diff, a command to generate a patch, this should be present on almost any unix system, however, it is probably also possible to find a win32 version on google.
now all we do to create the patch is to unpack the two different versions, so we get the dirs: “dokuwiki-2005-07-01” and “dokuwiki-2005-07-13” (this is the version change i did, your upgrade might be from/to different versions). now all we need to do is issue the diff command, and create the patch:
diff -Naur dokuwiki-2005-07-01 dokuwiki-2005-07-13 > doku.diff
now we have the patch, this is essentially only the differences between the two directories (e.g it knows nowthing of your pages, which is good) and you should be able to patch up, without it interfering with anything. however, you should not, that it might have changes in the conf/ dir in files you have edited, in which case you should do a backup of the file, copy the file from the version you already have, so the patch will work, and then when the patch is applied redo your changes, however this is only the case if changes to the dokuwiki standard php file is in an upgrade.
To check which files the patch will affect, you can run with –dry-run.. just cd into the dir where dokuwiki is installed, and run:
patch -p1 </path/to/doku.diff --dry-run
then if you accept it :) just run it like this, without –dry-run:
patch -p1 </path/to/doku.diff
Here is what you may want to do when everything is up and working.
footer.html
inside the dokuwiki/lib/tpl/default folder to represent the appropriate license:.htaccess
and set the appropriate config file option.style.css
to your own ideasThe topic of multi-wiki, or wiki farms, comes up briefly in freelists.org archives, in this thread, this thread, and this one. In the last one, Andi describes changes he made so $conf['title'] can be used to establish different cookies for separate installations.
Note that namespaces could be used to separate content in a single installation. And multiple installation means each one will need its own upgrade. It is not the same as multiple instances sharing common code. Package upgrades, like Debian’s, will not handle multiple installations. But for some this is a price worth paying. Here is an approach that worked with the GNU/Linux installation using Apache. It can probably be adapted to the other situations:
Do the first two steps once and repeat the last three to make multiple installations.