DokuWiki and WordPress Integration

How to use your wordpress authentication and user system on dokuwiki

UPDATE 2: If you have wordpress 3.x, this will no longer work. Go here for a fix.

UPDATE: This has been updated to work with the more recent versions of wordpress and dokuwiki (tested with WP 2.9.1 and DW 2009-12-25).

This ‘mod’ seamlessly integrates dokuwiki with your current wordpress installation. When you log in on one, you will be logged in on the other, and all the user info is exactly the same. The default roles in wordpress become the user groups in dokuwiki, and you can assign wiki permissions to them as usual (but can’t change/delete them). This requires minimal changes to your dokuwiki install and zero changes to wordpress (up to wp 2.6, otherwise there is a small change). You don’t need to know any php or anything else to complete this integration. The entire thing should take about 5 minutes.

We are going to be adding a custom authentication module to dokuwiki that will use the wordpress auth tools instead of the default dokuwiki ones. We will also be tweaking some settings so dokuwiki knows what it can and can’t do with user accounts, then setting it up so the wordpress roles become the wiki’s user groups.

Setup and Download
First, upload and install both wordpress and dokuwiki if you haven’t already. I suggest putting them in their own folders in the same directory, but it isn’t necessary. For example, my web folder looks like this:


Whatever your setup is, take note of it because we will need it in the next step. Now, download this zip and extract it somewhere accessible: DokuWiki Wordpress Integration (1714)

Step 1: The authentication module
Copy the keeyaiwp.class.php file from the zip into your wiki/inc/auth folder.

Now open it with an editor and find the line that says $wordpresspath = ‘../wordpress/'; It is the first line of code after all the comments. Change this to point to your wordpress folder, relative to your wiki folder. If you used the directory setup above, the default is fine. Make sure the trailing slash is there – the authentication won’t work if it is missing.

Step 2: Wiki configuration options
Navigate to your wiki/conf folder and find local.php. If it doesn’t exist, rename local.php.dist to local.php. This file contains some wiki settings, including telling the wiki to use our new authentication module. Open it up and add/edit the lines below. Note that @administrator is NOT @admin.

        $conf['useacl'] = 1;
	$conf['superuser'] = '@administrator';
	$conf['disableactions'] = 'register';		// Disable the ability to register: handle with wordpress
	$conf['autopasswd'] = 0;					// Disable password autogen: not important if users can't register
	$conf['resendpasswd']= 0;					// Disable password resend:
	$conf['profileconfirm'] = '1';		// password must be verified when editing profile
	$conf['passcrypt'] = 'smd5';			// Not sure what passcrypt needs to be set to, but this works
	// use wordpress login system
	$conf['authtype'] = 'keeyaiwp';
	// default group name
	$conf['defaultgroup']= 'user';

Step 3: Wiki permissions
Navigate to your wiki/conf folder and find acl.auth.php. If it doesn’t exist, rename acl.auth.php.dist to acl.auth.php. This file controls the default permissions for users and groups in your wiki. We are going to be adding the four lower wordpress roles (we already added the administrator role by setting it as the superuser) as wiki user groups. You should tweak these settings so your wiki behaves the way you want it to. The names are the wordpress roles – don’t change them – and the numbers are dokuwiki permissions. Here is the dokuwiki ACL documentation, but if you want to just jump into it, the numbers are 0=none, 1=read, 2=write, create=4, upload=8, and delete=16. Just pick the highest number you need – each one includes all the permissions below it. My defaults allow everyone to read, all logged in users (subscribers, contributors, and authors) to read/edit/create pages, and allows editors and administrators to upload media and delete pages. Only users in the administrators group have access to the wiki’s admin tools.

Open the file and add the following lines (with any adjustments as described above):

	*               @ALL        	1
	*		@editor		16
	*		@author		4
	*		@contributor	4
	*		@subscriber	4

Step 4: WordPress Function Edit
The problem with the newer installations is a redeclaration of the function is_ssl. To fix it, we are going into the wordpress files and telling it to only define is_ssl if it doesn’t already exist. Open wp-includes/functions.php and search (usually ctrl-f) for function is_ssl and change it to look like this by adding the lines and curly brackets at the beginning and end. In WP 2.9.1 it starts at line 3091.

if(!function_exists('is_ssl')) {
function is_ssl() {
	if ( isset($_SERVER['HTTPS']) ) {
		if ( 'on' == strtolower($_SERVER['HTTPS']) )
			return true;
		if ( '1' == $_SERVER['HTTPS'] )
			return true;
	} elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
		return true;
	return false;

That’s it! Pretty easy, huh? Now your blog and wiki sign-ins should be perfectly in sync. After doing the above steps one time, you can use the wiki admin tools to further adjust permissions for users and groups, so you should never have to get into the code again.

If you had any problems or have suggestions, please leave a comment. Bug reports, feature requests, link backs, and thank yous are all immensely appreciated.

Leave a comment ?


  1. DokuWiki and Wordpress Integration - pingback on September 27, 2008 at 7:29 pm
  2. Once again, googling my problems leads me to your blog. Goddammit Collin. Thanks for already having done this for me.

  3. 😀 Problem is, I need people I DON’T already know coming here! Glad to help anyway.

  4. Thanks. I found this page with a simple google search and it worked great. I use dokuwiki for my RPG games with WordPress as my front-end. Since I have one wiki per game it was a monumental PITA for logins. This worked the first time out.

  5. It is great to hear when something goes right! I understand how much of a pain multiple logins can be; glad I could help make it easier for you.

  6. I also googled and found… I just tried installing and the install went well but it doesn’t seem to be working… I’ve authenticated with WP in another tab so I know my username/pw is correct… In my DW tab, I have tried logging in and I get successfully logged in but my ACL is as @ALL but in WP my account is set as ‘editor’.

    I did discover that DW is picky about the format of acl.auth.php. The fields must be delimited by instead of … Having done that, however, I have set @editor to 16 and @ALL to 1… If I set @ALL to 0, then when I log in as myself, I have no rights to view the page. This is how I’ve determined that my rights fall under @ALL instead of @editor…

    from wp_usermeta:

    | 13 | 2 | wp_capabilities | a:1:{s:6:”editor”;b:1;} |


  7. I’m working on this now but ideally I would like to have the wiki be a subdomain of the wordpress blog eg. Any ideas how I would setup the paths correctly in that instance?

  8. @ganish: I’m not sure what is causing your problem — your account DOES work on WP as editor, but only as all on DW? Have you modified your permission setup in WP from the default at all, or installed any plugins that might deal with roles or the like?

    Unfortunately, this was my first foray into WP authentication, so I’m not sure what is causing your problem.

    Also, I haven’t had to change my delimiter as you mentioned above – perhaps changing it is part of the issue.

    See if you can get any more useful information – we will track this down and get you up and running!

  9. @timmmmyboy: Have you tried anything yet and are having trouble, or are you just looking for advice?

    On my hosting, a subdomain is just a sub-folder and I set the server to direct there when a user tries to hit that address (ie, requests to go to The first thing I would try is changing the wordpress path in keeyaiwp.class.php to point to the subdomain – if that doesn’t work, try the subfolder. If neither of those work, post again and we will sort something else out.

  10. ricardoquesada

    I’m having problems using the plugin with WP 2.8.
    It seems that it has problems when it includes the wp-load.php file.

    any idea ?

  11. @ricardoquesada: honestly, I haven’t even looked into using it with 2.8 yet. The site that I have them integrated on is still running 2.7.x.

    Can you give me any more info on what problems it is having when including wp-load.php?

  12. Hello! The problem is this patch:

    If you restore the /inc/init.php from a previous version everything works… but don’t forget that this is a security problem.


  13. WordPress整合DoKuwiki » 深度工作室 - pingback on August 9, 2009 at 4:12 am
  14. Álvaro Degives-Más

    Well. Bookmarked, in case a 2.8.x fix rolls around… Awesome hack nonetheless.

  15. I’ll get around to it one of these days…

  16. I’m hoping you’ll update this for WP 2.8 as well. It seems like it would fit my needs perfectly.

  17. Hmmm. The solution isn’t trivial so I’ll have to dedicate some actual time to figuring out what is going on. Any insight would be useful when I get to it.

  18. I am really looking forward for this.

    Good luck and Thank you

  19. Hello

    I’m trying to implement this code but I originally installed the contents of wordpress in so it’s not in some folder called WordPress or anything. If I the contents in a folder, it messes up everything. So what do I do for the wordpresspath?

    The dokuwiki file is also under mysite/html/

    Thank you in advance for your help!

  20. @jetlej: so, you have all the internal dokuwiki and wordpress files in the same folder? Like, you see doku.php and wp-content in the same directory? If so, and you’re using the older versions that this works for, your wordpress path should probably be just ‘.’ That is really not the most ideal setup though as you could start running into overlaps.

  21. So it’s necessary to find a way to put wordpress in it’s own folder and re-route everything?

  22. @jetlej: not at all — put ‘.’ as your wordpress path.

  23. I mean because of the overlaps. Are they a big enough problem to need put wordpress in it’s own folder. This is for a site I’m building for a business so it’s very important I get it right

  24. You’ll just have to try it and see if you get any errors, most likely with things already being declared or just being totally wrong because a file for one was overwritten by a file for the other. It’s totally up to you though. If it works, it works.

  25. Thanks a bunch for bearing with me. I put WordPress in its own directory and am running 2.7.1. After I implemented the above instructions, I got this error: Fatal error: Cannot redeclare is_ssl() (previously declared in /nfs/c04/h01/mnt/60563/domains/ in /nfs/c04/h01/mnt/60563/domains/ on line 2806.

    Any ideas?

  26. Sorry to ask again, but it’s the last thing I need to fix for this site. Do you have any idea why it’s not working for me?

  27. You have a function is_ssl() being defined in both wordpress and dokuwiki. I haven’t looked at the sources, but you’ll need to go look at each one in the file/lines indicated in your error and see what they do. If they do exactly the same thing, you should add an if block around the code that defines the functions — if(! function_exists()){ function is_ssl() … }. I doubt they are the same though, so you’ll probably need to rename one of the functions (maybe doku_is_ssl()) and update all the places in the wiki code that calls it. Sorry, not an easy or elegant solution.

  28. Worked like a charm. Thank you SOOO much for all of your help

  29. Good! What solution did you use so others can get theirs working and I can update the page?

  30. Tried this and received an exception in /wp-includes/user.php at line 70. Any ideas?

    [code]add_filter(‘authenticate’, ‘wp_authenticate_username_password’, 20, 3);[/code]

  31. @Jon: I know exactly what the problem is. I posted an intermediate version instead of the full working one, so I basically gave you a crap file. My fault there.

    Re-download the packet and the correct keeyai.wp.class.php file should be there.


  32. Don’t apologize…I’m just glad it’s not me! I’m excited all over again :)

  33. Are you sure the file is different? It’s still dated 11/6/2009…or am I downloading from the wrong location?

  34. The link above is to the new file — I verified it is from today. Here is the link again in case something weird is going on:

  35. I guess it’s just not working for me then. I still get the same exception error.

  36. @Jon: it shouldn’t be loading users.php at all — that was test code that shouldn’t have been released. If you can’t make the download work, try editing the keeyaiwp.class.php file and changing wp-includes/user.php to /wp-load.php

  37. Cool thanks! Will give that a try and let you know how it goes.

  38. Well, I messed around with it a bit and I’m guessing it’s the sidebar login plugin I’m using for WordPress that’s interfering. I was able to load the page, but there were a few lines of errors at the top. I may give it a try without the sidebar login and see what happens later. I also noticed that that my wp-load.php file was in my root directory and not in wp-includes.

  39. I deleted everything I was working with, cleared my cache and then re-downloaded the file. Long story short…it worked that time around!

    I had long considered if I even wanted an integrated logon system for the wiki as it’s sort of a separate entity, but now that I have it to put in place, I think it will be terrific.

    Thanks so much for this mod and for the help in getting it to work!

  40. Hmmm…everything works great except this mod seems to have introduced and escape backslash problem. Single and double quotes are now converted to \’ and \”. I’m on shared hosting with 1and1 so editing .htaccess is out. I tried to disable magic quotes using php.ini, but it made things worse (created additional backslashes).

    Any ideas?

  41. @Jon: Glad you got it working, at least part of the way. I haven’t run into that problem myself — there must be a setting in WP or DW that is affecting the other since additional magic quotes get appended with the php.ini setting.

    Are the extra slashes in the wiki or the wordpress, or both? Maybe we can track down what is causing it.

  42. Only in the wiki. I tried to disable it using a php.ini thinking it was magic quotes being enabled, but it went from don\’t to don\\’t. If I go back to default login mode, it goes away.

    I also tried adding a few snips of code I found on the Internet to manipulate various forms of magic quotes and addlslashes(), but it didn’t help.

    I did have this issue on my wordpress ages ago, but fixed it with a few lines of code somewhere…I don’t remember now.

  43. I suspect it has something to do with a dokuwiki filter that does it automatically, but loading the wordpress files handles it before that. Sorry, I haven’t been deep enough in the code for a long time to give you better direction than that.

  44. Hi,

    this may save time and searching to others, I have dokuwiki AND WordPress in the root of my site. So both the dokuwiki folder and wp-load.php file (and the wp-admin, wp-content, wp-includes folders) are in the same (root) folder.

    In keeyaiwp.class.php, REPLACE:
    // define WP — change this to fit your installation. Make path relative to wiki directory
    $wordpresspath = ‘../wordpress/'; // dont forget the trailing slash

    $fullpath = fullpath(DOKU_INC . $wordpresspath);

    // define WP — change this to fit your installation.

    $fullpath = $_SERVER[‘DOCUMENT_ROOT’];

    hope this helps someone

  45. First of all, thanks for updating this, it’s exactly what my site needed.

    However, I get the same behaviour with \’ and \” as Jon. If anyone finds a solution, please post it here!

  46. Confirming the addslashes issue. Did some research, but all I could find is that without this mod (great work!), all is fine, with it, addslashes turn up. Magic Quotes are off, configuration settings are ok (tried all 3 varieties)

    Just a long shot, but maybe this:

    # If your auth backend allows special char like spaces in groups
    # or user names you need to urlencode them (only chars <128, leave
    # UTF-8 multibyte chars as is)

    in the header of acl.auth.php.dist is a clue?

  47. As posted on the dokuwiki forum as well:

    for anyone interested, I wrote a plugin to stripslashes before writing a wiki page. This doesn’t work on EDIT/UPDATE existing (!) pages, but if you cut all content from such a page, save the (now) empty page, then instantly re-create the page, and paste the same content, you’re fine. At least, it works for me.

    Of course this is still a workaround, and not addressing the cause of the issue be it the keeyaiwp bridge, or dokuwiki.

  48. Googpress – the vanweerd sandbox» My First DokuWiki Plugin - pingback on February 5, 2010 at 11:48 am
  49. I too am experiencing the addslashes bug which seems to be stemming from wp-settings.php around line 630 in WordPress 2.9.1:

    // Escape with wpdb.
    $_GET = add_magic_quotes($_GET );
    $_POST = add_magic_quotes($_POST );
    $_COOKIE = add_magic_quotes($_COOKIE);
    $_SERVER = add_magic_quotes($_SERVER);

    Wrapping this with an if statement to check if the cookie is from Dokuwiki or somewhere else seems to fix the problem and I haven’t seen any adverse effects yet. The final code looks like:

    if (!$_COOKIE[DokuWiki]) {
    // Escape with wpdb.
    $_GET = add_magic_quotes($_GET );
    $_POST = add_magic_quotes($_POST );
    $_COOKIE = add_magic_quotes($_COOKIE);
    $_SERVER = add_magic_quotes($_SERVER);

    Basically just skips WordPress’s slashing if the Get/Post/Cookie request comes from Dokuwiki.

  50. Did anybody else have Doku wiki break after updating WordPress to 2.9.2?

  51. @Butch: You’ll need to reperform step 4 above and potentially the edit to wp-config I mentioned each time you upgrade WordPress as these files will be replaced by WordPress.

  52. **Slaps head**

    I swore I was going to remember that core edit. So much for change management. :)

  53. My First DokuWiki Plugin | van Weerd - pingback on May 2, 2010 at 8:24 am
  54. Just a note that now all of this:

    // Escape with wpdb.
    $_GET = add_magic_quotes($_GET );
    $_POST = add_magic_quotes($_POST );
    $_COOKIE = add_magic_quotes($_COOKIE);
    $_SERVER = add_magic_quotes($_SERVER);

    is located within load.php instead of wp-settings.php since WordPress 3.0.

    This took a bit of headscratching, but I was able to track down the location. Also a confirmation that jwagner’s solution to the slash issue does in fact work perfectly.

  55. Tried it, but always get redirected to WIKI_DIR/wp-admin/install.php
    Originally had the wiki in a subfolder of wordpress, but changing it to your suggestion (parallel folders) doesn’t work either. Any idea, what the problem might be?

  56. Was it working before changing the authentication? I haven’t delved into either codeset for a while but I think redirecting to install.php is a symptom of not being fully installed.

  57. I thought that at first too, but the wiki works great if I use standard authentication. Even if it was a wiki problem, shouldn’t it redirect me to WIKI_DIR/install.php and not WIKI_DIR/wp-admin/install.php?
    I’ve tried some more today, using different folder location and definitions of fullpath, but always to the same result (WordPress 3.0.3 and Dokuwiki “Anteater”). Sadly the server log reports nothing useful.

  58. That is an excellent point; it definitely looks like the problem is on the wordpress side. Does the wordpress install work on its own as well?

  59. Yes, wordpress works well on its own, too.

  60. I’m having the same problem as “testing” I got it all set up, but whenever I try to access it, I’m getting 404 errors pointing to install.php. I do have pretty permalinks enabled, but I don’t know that it’s relevant. The Wiki works so long as I don’t have the local.php and acl.auth.php files present. When those files are present in the “conf” directory, however, the wiki doesn’t work.

  61. I’m fairly certain that this has something to do with some recent changes to the wp-load, wp-config, or wp-settings files. I can’t tell any more than that. For whatever reason, it seems like the calls to check for existing configuration are returning false, which triggers the wordpress installer. I’m not sure I’m savvy enough to tell more than that.

  62. I’ve been trying to figure out what they did with the new WP version so I can fix this. I’ve narrowed the problem down to the database object. Initially the table prefix doesn’t get set correctly, but when I manually fix that it can’t connect to the database. So far I’m terribly frustrated with WPs overzealous use of globals and their crazy init code that jumps all over the place.

Leave a Comment

Trackbacks and Pingbacks: