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.
Matthew K. Gold
Boone Gorges
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.
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/gmu/wiki/LocalSettings.php on line 132
Notice: Use of undefined constant �extensions - assumed '�extensions' in /var/www/html/gmu/wiki/LocalSettings.php on line 135
Notice: Use of undefined constant AuthWP - assumed 'AuthWP' in /var/www/html/gmu/wiki/LocalSettings.php on line 135
Warning: Division by zero in /var/www/html/gmu/wiki/LocalSettings.php on line 135
Notice: Use of undefined constant AuthWP - assumed 'AuthWP' in /var/www/html/gmu/wiki/LocalSettings.php on line 135
Warning: Division by zero in /var/www/html/gmu/wiki/LocalSettings.php on line 135
Notice: Use of undefined constant php� - assumed 'php�' in /var/www/html/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/gmu/wiki/LocalSettings.php on line 135
Fatal error: require_once() [function.require]: Failed opening required 'php�' (include_path='/var/www/html/gmu/wiki:/var/www/html/gmu/wiki/includes:/var/www/html/gmu/wiki/languages:.:/php/includes:/usr/local/lib/php:/usr/local/php/lib/php') in /var/www/html/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/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 ^^
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
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