WPMu Single Sign-on is a package of extensions for MediaWiki that creates a single, shared login system for MediaWiki and WordPress Multi-User.
Developed and customized by Cast Iron Coding for the CUNY Academic Commons, and released under a GNU General Public License, this package includes and builds on the following extensions:
AuthWP.php, by Ciaran Gultnieks
LockDown.php, by Daniel Kinzler
and
LogoutLoginWP.php by Cast Iron Coding and The CUNY Academic Commons
Download the WPMu Single Sign-on package here. (zip file)
WordPress Multi-User/MediaWiki Single Sign On Setup Instructions
Tested on:
MediaWiki version 1.13.4
Wordpress Multiuser Version 2.7.1
Assumptions:
Wordpress Multiuser and MediaWiki are installed on the same server, in the same webroot. WPMu is installed in the webroot and MW is installed in a folder called wiki/. The locations of the applications relative to the webroot could be changed, but changes to several of the extensions and the htaccess configuration may be required to make it work.
MediaWiki Extensions
Lockdown
-
Lockdown is a MW extension which serves here to restrict user access to “Special” pages, in this case the Preferences page. Logout will continue to serve as the login, and Login will be redirected to WP using the LoginLogoutWP extension below.
Lockdown configuration
Add the following code to LocalSettings.php:
require_once( $IP.'/extensions/Lockdown/Lockdown.php');
$wgSpecialPageLockdown['Preferences'] = array('');
AuthWP
-
AuthWP is a MW extension that was created to create a single-sign on between WPmu and MW.
AuthWP Modifications
I found I needed to change require() calls to require_once(): [lines 38-39]
require_once($WP_relpath.'/wp-load.php');
require_once($WP_relpath.'/wp-includes/registration.php');
AuthWP configuration (in LocalSettings.php)
# Include the AuthWP.php extension
require_once('extensions/AuthWP/AuthWP.php');
$wgAuth = new AuthWP();
LogoutLoginWP
-
The LogoutLoginWP is a custom extension inspired partially by the RedirectAfterLogout extension. It’s purpose is to tie up some loose ends in the login / logout process. Specifically, it consists of two functions registered as MW hooks. The UserLogout hook is called after the user has logged out. Since some of our logouts will come from WP (via a mod_rewrite rule, see below), we want to continue to redirect back to the redirect_to URL from the query string. The UserLoginForm hook is called before the login page is displayed. Our code redirects the user to the WP sign in page at this point.
LogoutLoginWP configuration (in LocalSettings.php)
# Include the redirection extension for WP
require_once($IP.'/extensions/LogoutLoginWP/LogoutLoginWP.php');
.htaccess Configuration
-
The following mod_rewrite rule is added to the .htaccess file at the site root:
# Rewrite a WP logout request to logout from Mediawiki instead, which takes care of both.
RewriteCond %{QUERY_STRING} ^action=logout.*$
RewriteCond %{REQUEST_URI} wp-login.php$
RewriteRule ^.*$ wiki/index.php?title=Special:UserLogout [QSA,L]
MediaWiki Sysop
When these extensions are activated, the admin account of the WPMu installation must be manually set as the administrator of the MediaWiki installation. Admins can do this by manually editing the MySQL database. In the MediaWiki table “user,” set the user_name field of the WikiSysop user to the account username of the admin in WPmu. However, the first letter of the admin name must be capitalized in the MediaWiki user record.
If logging into WPMU then on the wp-login.php link add a ?redirect_to=htmlencoded_url
This comment was originally posted on bavatuesdays
*Really* exciting stuff here. To my eyes, CUNY is almost perfectly positioned to take us all to the next level. Location, mission, ethos, it’s all there. Your post on CUNY was breathtaking and made me even more grateful to know and collaborate with the great folks there. It’s a wonderful seminary for the reverends in us all.
This comment was originally posted on bavatuesdays
This rocks. I’ve been going straight off of wikis lately. Not from a conceptual angle, but certainly from an implementation-related angle. User management in Mediawiki has been a chore. Thank you CUNY.
One more gripe on wikis – is it just me or do they feel like the dot-matrix printer paper of the web? Give me a blank sheet of paper and I’ll draw or make a paper airplane. Give me dot-matrix paper and I’ll print you off an invoice for a used Chevette. Give me a wiki, and despite all best intentions, I’ll start typing help pages or encyclopedic rubbish.
This comment was originally posted on bavatuesdays
So, are these cool plug-ins and stuff going to be made a part of the testing platform for the institutions interested in the WPMu stuff? You know why I’m asking.
@ken It depend on who you have creating the wiki, and the goals. I suspect it’s just a case of public resources being more public and open than other wiki uses.
This comment was originally posted on bavatuesdays
@Ron,
How did i know you’d know. Now help a brother out and let me know where exactly I would put that snippet in wp-login.php. Is there a specific line of code I need to append this to, or am I just totally ignorant?
@Gardner,
I couldn;t agree with you more about CUNY, and my short time there was inspiring. In fact, much of what I talked about with several folks was your time at the Baruch Symposium. You made a deep impression, and I think that all this stuff comes full circle when we start to re-imagine it in terms of the mission of a public, under-funded educational monolith like CUNY. More to the MediWiki point, I think this first integration may actually be key in developing out the wiki farm so that any instructor or student can get a mediawiki space as something they can maintain and control while at the same time allowing for a general purpose and wide open wiki for anyone in the UMW Blogs community. it has been a long time coming, but we may finally be able to devote the necessary time and attention this Summer. Here’s to hoping.
@Ken,
I agree about wikis, I ahve been avoiding them more and more these days, and I am trying to re-imagine that. I have been thinking more and more that wikis are great for one or a ton of users, but not for a small group, but Steve Greenlaw in the Economics department at UMW still uses wikis to great effect, as does Jeff McClurken—so I think it is high time to get over my prejudices and try to make MediaWiki work more fluidly. That’s the crazy thing about this stuff, we can actually set out and make it work for us! Congratulations, btw, just read your blog, papi!
@Steven,
Yeah, this stuff is coming out incrementally, and I think this is the first of many plugins from CUNY, and I’ll be blogging anything they throw out there. Their work at the Academic Commons, as well as Blogs@Baruch and the Macaulay Honors college opens up some real development and integration possibilities given the scale they could be working on, and that is exciting, and will certainly feed into EDUBACON
This comment was originally posted on bavatuesdays
may the force be with you.
This comment was originally posted on bavatuesdays
Thanks so much for pimping this plugin, Jim. This is the first time I’ve been part of an effort that has resulted in code being released to the wider open-source community, and I have to say that it feels amazing to give something back.
Although this single sign-on is important, I think we need a couple more steps to really reach “wiki farm” status. Ideally, every individual and group in a WPMu install would be able to have his or her own wiki space that, rather than living inside of the mediawiki install, gets imported back into the BuddyPress profile space (perhaps through the bliki work that you guys have done here at UMW). That, I think, is one of the next steps we’re going to try to take at the Commons — rethinking how groups, for instance, can create their own spaces (including discussion boards, blogs, etc.). We really want to rethink/rework the group interface; allowing each group to have its own wiki (perhaps defined via mediawiki’s category functionality) will be a major step there.
At any rate, thanks again for everything. And, yes, both Gardner’s symposium workshop and your CUNY WordCampEd are already the stuff of legend!!
This comment was originally posted on bavatuesdays
I am using for the Wiki and WPMU different subdomains. Any idea how to adjust the plug-ins to get this set-up to work? I get your plug-ins to work in a single subdomain test environment, but with different subdomains, any request of a wiki page is directly redirected to the front page of the WPMU subdomain.
Far be it for me to differ with the bava, but I have a quibble with one phrase from this post: “…growing belief that anything you can do in a wiki you can do in a blog better.”
Maybe, but I’ve always found wikis to be much better in the drafting phase of collaborative writing. Maybe I’ve been reading too much Abject Learning. Just saying.
This comment was originally posted on bavatuesdays
Steve,
I agree with you, and that is why I need to re-visit the wiki in more depth, more specifically MediaWiki—my favorite. I also need so Brian Lamb love int his regard, I am going to Vancouver in August as a kind of WPMu detox so I can get back in touch with my wiki side.
This comment was originally posted on bavatuesdays
It was Brian who got me started with wikis and web 2.0!
This comment was originally posted on bavatuesdays
Thanks so much for releasing this!!
I’m also with Wiel on this, I’d like to have:
WPMU: example.com
MW: wiki.example.com
Is this possible? Also, any idea how I would change those .htaccess rewrites for use on lighttpd instead of Apache?
Thanks for your responses, Alex and Wiel. Lucas Thurston, the author of our extension, is working on the redirect issue and should have a new release soon. We’ll let you know when it’s up.
Having some trouble installing, after following all the steps the mediawiki site just turns up blank, no error message nothing…have it installed under http://[my-domain]/wordpress-mu/wiki/, with WPMu 2.7.1, and I reconfigured the .htaccess file of WPMu as in the last step of the install process…any ideas? Thanks!
Never mind, had installed Mediawiki 1.15.0, now with 1.13.4 it works perfect…must’ve been some compatibility issues
Mathew, thanks for the great guide, but would you happen to know how would these .htaccess rules translate into nginx rewrites? Can’t figure that out 🙁
Hmmm, I’m not sure what’s going on with my installation. When I add the changes to the localsettings.php, my main wiki page comes up blank. I’ve tried it with MediaWiki 1.15 as well as 1.13.4. Has anybody else had this problem?
Hi Mark,
I remember that this happened to me once when I installed the set of extensions, but I can’t remember how I solved it. I’ll ask one of our developers to troubleshoot this for you tomorrow.
in the meantime, here are two suggestions:
1. Please double-check that you’ve installed all of the plugins in the appropriate directories.
2. You might turn on PHP error reporting to see whether that gives you any clues about the nature of the problem.
We’ll be in touch soon.
Thanks for getting back to me so quickly! I’m getting a bunch of errors:
Notice: Use of undefined constant � - assumed '�' in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 132
Notice: Use of undefined constant �extensions - assumed '�extensions' in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
Notice: Use of undefined constant AuthWP - assumed 'AuthWP' in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
Warning: Division by zero in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
Notice: Use of undefined constant AuthWP - assumed 'AuthWP' in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
Warning: Division by zero in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
Notice: Use of undefined constant php� - assumed 'php�' in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
Warning: require_once(php�) [function.require-once]: failed to open stream: No such file or directory in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
Fatal error: require_once() [function.require]: Failed opening required 'php�' (include_path='/var/www/html/commons/www/gmu/wiki:/var/www/html/commons/www/gmu/wiki/includes:/var/www/html/commons/www/gmu/wiki/languages:.:/php/includes:/usr/local/lib/php:/usr/local/php/lib/php') in /var/www/html/commons/www/gmu/wiki/LocalSettings.php on line 135
About my installation: both WPMU and Mediawiki are working fine on their own; Mediawiki only “breaks” after I add the extension code to LocalSettings.php. I have WPMU installed in a /gmu/ directory and MW in /gmu/wiki directory.
Thanks worked a treat! Did have an issue copying and pasting the single quotes, maybe Mark had that issue?
Mark,
What’s on line 132 and line 135 of /var/www/html/commons/www/gmu/wiki/LocalSettings.php?
Zach
I checked lines 132 and 135 and indeed, the straight quotes had been pasted in as “smart” quotes. I’ve fixed those, and now I’m not getting any errors, but neither is anything showing up on the page, which is here.
And here is what the tail of my LocalSettings.php looks like:
# Error Reporting
error_reporting(E_ALL);
ini_set(“display_errors”, 1);
# Include the Lockdown Extension for WP/Mediawiki Integration
require_once( $IP.’/extensions/Lockdown/Lockdown.php’);
$wgSpecialPageLockdown[‘Preferences’] = array(“);
# Include the AuthWP.php extension
require_once(‘extensions/AuthWP/AuthWP.php’);
$wgAuth = new AuthWP();
# Include the redirection extension for WP
require_once($IP.’/extensions/LogoutLoginWP/LogoutLoginWP.php’);
Blank screen usually suggests a fatal PHP error with error reporting disabled. Is PHP error reporting still enabled?
Yep – still have error reporting on. If I remove the lines from LocalSettings.php dealing with the MediaWiki/Wordpress integration, the wiki loads up just fine.
The quote before “display_errors” looks like a smart quote – can you check that?
Zach
The quotes in the require_once calls also look like the mighty be smart quotes.
I think those quotes must have been converted to smart quotes by your WordPress — they’re straight quotes when they appear in my LocalSettings file.
Mark,
Can you comment out the integration related lines in local settings one at a time? Reload between each line and try to isolate which line is causing the problem.
Zach
Any update on the way around editing the .htaccess ?
I have needs for this on a shared hosting account. Unfortunatly moving to a host other than godaddy is not available to me in this instance.
I am writing about this development of yours at my site, I will gladly link over to you!
Fantastic work!
Hey guys this thing is incredibly great!
However I’ve encountered 2 issues. Whenever I want to activate the AUTHWP I get a white page. I’m not sure it’s the same problem as Mark’s.
1. Whenever I comment out these lines I get everything fine:
# Custom: Include the AuthWP.php extension
//require_once($IP.’/extensions/AuthWP/AuthWP.php’);
//$wgAuth = new AuthWP();
2. The .htaccess modifications are added to the wiki/ folder’s root in a new .htaccess right?
Thanks very much for your help, very much appreciated!
I hadn’t had a chance to go through this process myself until this afternoon, when I did the setup for a project I’m involved in. Once I had WPMU and MW running, it took literally five minutes for me to put the rest of it into place. Worked flawlessly. Totally awesome – nice work Cast Iron Coding!
I’m glad to hear that it worked smoothly for you, Boone — that was my experience, as well. And I agree that great kudos are due to the Cast Iron Coding team.
Cheers for these great set of tools to integrate the login between buddypress and mediawiki. I was also wondering how you were able to have the buddypress/wordpress header, footer and admin bar on the wiki. As this really allows for full integration for user experience.
Thanks for the plugin, but it creates some problems:
The mutual sign-in/sign out seems to work as promised to that is a great start 🙂
But after signing in on WPMU 2.8.4a/BP1.1.1 and going to MediaWiki 1.15.1 the admin can do everything. But a regular user is still logged in, but when trying to edit I get the following message:
“You do not have permission to edit this page, for the following reason:
You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.”
When clicking the link for “user preferences” in the message above, I get:
” Permission error
The action you have requested is limited to users in one of the groups: *, Users. ”
Before the integration MW users could edit and such, what do I need to change to get it working again?
Thanks for your help and great work,
Cheers, Harry
Hi Harry,
This extension has not been tested with the versions of WordPress and Buddypress that you’re using (please see the note at the top of this post regarding versions).
When we upgrade the Commons to the latest versions of WPMu and BuddyPress, I’m sure that we’ll update the extension as well, but until then it might be best to either not use this extension or to dial your platforms back to latest versions supported by the extensions.
Happy blogging!
Hi Matthew, thanks for the quick reply.
Actually I noticed that the first problem was not caused by new versions, but by this setting which I had: $wgEmailConfirmToEdit = true;
As all users had been confirmed until the integration, it was never a problem. Now it works, but you could mention it in your instructions above.
The 2nd problem (no preferences page) seems to be by design (LockDown), what is the reason for blocking off editing the preference pages completely?
Would it be possible to only block changing the password (I assume that is why it was blocked in the first place?) .
Thanks in advance,
cheers, Harry
If you’re using this, you should make sure you have the latest version of WPMW (AuthWP.php) which can always be found here: http://projects.ciarang.com/p/WPMW/source/download/master/
It doesn’t work with me. MW seems not find the WP db. It says that the user doesn’t exist.
Been searching on the web for something like this. Hopefully it still works ^^
Hi!
This extension is a great job!!
..is there a way to make it works with WPmu 2.9, BP 1.2 and MediaWiki 1.15??
It will be very useful to take this extension updated!
Saki
This is a really great plugin and I have gotten the SSO from wordpress to Mediawiki working, however, the logout is not logging our users out of MediaWiki. I have .htaccess configured like the instructions say, except I had to modify the following because the way our wiki farm is configured:
RewriteRule ^.*$ wikis/wiki001/index.php?title=Special:UserLogout [QSA,L]
Any help you can give would be much appreciated
This is just AWESOME! Once I installed it, I had to make a tiny bit of changes to the Mysql db, but changing the require to require_once wasn’t required for me. Now I can finally have one log in, using one account. Anyways, this helped me a lot!
Is this the Mysql query in PhpMyAdmin?
UPDATE wiki_user SET user_password=md5(concat(user_id,’-‘,md5(‘wordpressadminpassword’))) where user_id=’1′;
well, nice work, however it would be nice to have the usual tools to track and discuss the project, e.g. trac or guthub or ANYTHING not just a blogpost. THANKS!
When I upload the plugin I get this:
The plugin does not have a valid header.
Am I right in thinking that I just need to upload and network activate the plugin or do I need to change all the code as listed?
Thanks in advance.
I installed your solution and followed the instructions step by step. After that, things works to a certain extent (after the login to WP, the account also works for MW).
But the log out in MW produces following error screen:
Fatal error: Cannot access protected property WebRequest::$data in /home/paulpost/public_html/fasos.org/mc1011/wiki/extensions/LogoutLoginWP/LogoutLoginWP.php on line 29
So the account remains logged in at MW (where this erroneous MW log out did result in a logout on WP)
Furthermore, using Log in / create account at MW produces following error screen:
Not Found – The requested URL /wp-login.php was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Any clues? (working with WP 3.0.1 and MW 1.16 here)
It’s all already a while ago, WordPress 3.0 and Buddypress 1.2.4. have arrived and, hehe, the shared login procedure still works! The logout hook is broken though, and I was wondering whether there is any time in sight when you might update the WPMU Single Sign-on extension? It’s a gem!
Thanks for your report. We will look into this issue and reply shortly.
Thanks Matthew. Let me know if you need any more specific information on what goes wrong with the logout hook. I see you are in the middle of preparing for upgrading CUNY Academic Commons to WP 3.0 with Release 1.1., so I guess you can reproduce the problem quickly with your test environment, but I am glad to help and provide more info.
HI Andreas — more information is always good! If you have time, please let us know by commenting on this thread or by quickly creating an out on our Redmine installation and commenting on the ticket I created for this issue. Thanks!
Turned on error reporting via Comment 72 by Mark, and get this error:
Fatal error: Cannot access protected property WebRequest::$data in /Users/Frankly/Sites/dip.youthstudies.eu/wiki/extensions/LogoutLoginWP/LogoutLoginWP.php on line 29
Line 29 is this:
if($redirectTo = $wgRequest->data['redirect_to'])Ha! Problem solved, at least for me 🙂 Line 29 in LogoutLoginWP.php needs to change to
if($redirectTo = $wgRequest->getVal('redirect_to')) {With MediaWiki 1.16 a public field became protected, causing the hiccup.
Hi, thanks for this great stuff !!!
It works with WP 3.0.1, BP 1.2.5.2 an MW 1.16.0 (with the fix from Andreas – September 19, 2010, 4:01 pm) 🙂
One question? How do you realized the “wiki-link” in the navigation bar and that the wiki comes like a “BP-Page” ???
Hi, I’ve followed all the above and I’m stuck with it just redirects to the homepage. eg http://www.es.science3point0.com/cienciawiki directs to http://www.es.science3point0.com
I’ve worked out it’s something to do with Auth WP, if I remove the code below it does not redirect:
# Include the AuthWP.php extension
require_once(’extensions/AuthWP/AuthWP.php’);
$wgAuth = new AuthWP();
I havent played with the usernames, but both usernames are set to Mark.
Any help would be more than appreciated. (WP 3.0.1 BP 1.2.6)
I have an update. I have got it working on a normal domain, but not a subdomain address. Any ideas?
Thanks for the work! I have a slight problem: I installed my wiki in the main root, then installed BP to a folder (“Community”), e.g. a reversal of the prescribed setup. Is it still possible to use the single sign-on extensions? what modifications would I need to make? Grati.
thanks for this great solution — just installed it (WP 3.1, MW1.16.2) with minor tweaks to account for location of WP and MW installation folders. so far looks great! (still needs a bit more testing).
i do have one question though if this post is still being monitored. is there a simple way anyone can recommend for using the WP role to determine WM user group? i’d like to limit wiki editing to WP authors with all “subscriber” level WP users limited to the blog and forum. right now, WP subscribers can also edit the wiki.
Nicely done, and still works with current WP and MW. One point that doesn’t seem to have been addressed — this configuration does not seem to allow for mod_rewrite/ short URLS/ pretty links.
Is the source maintained/updated for each update to WP and MW software?
Curious because I would like to try to add this functionality to a site of mine.
“Chase says
Is the source maintained/updated for each update to WP and MW software?”
I for one surely hope so, since I am in the midst of configuring a WordPress+BuddyPress+MediaWiki configuration.
One would think that since WP is the most used free CMS, BP the most used free Social Community plugin and MediaWiki the most used webbased application for an encyclopedia, a lot of users have run into these kinds or similar like problems with a wish to have this fixed.
So I am just as curious as earlier poster:
a) Is this plugin still maintained
b) If not, is there another dev team working on a similar solution to make SSO between WP, BP and MW possible?
c) If not, would it be possible to gather up some people online available with both the knowledge and time (say at least 1 hr. per week on average) to make this possible?
James, Star Trek Online’s Fleet Admiral of The Immortal Ones
If getting error in accessing MW then check Auth.php file line no 30.
It should be like that:-
require_once(‘includes/AuthPlugin.php’);