From Organic Design wiki

WordPress is a free and open source blogging tool and a content management system (CMS) based on PHP and MySQL. It has many features including a plug-in architecture and a template system. WordPress is used by over 14.7% of Alexa Internet's "top 1 million" websites and as of August 2011 manages 22% of all new websites. WordPress is currently the most popular blogging system in use on the web, powering over 60 million websites worldwide. It was first released on May 27, 2003, by founders Matt Mullenweg and Mike Little as a fork of b2/cafelog. As of April 2013, version 3.5 had been downloaded over 18 million times.

Using MediaWiki accounts on Wordpress

We needed to have a Wordpress site which is seamlessly connected to a MediaWiki so that users can register and login using the MediaWiki login and registration process only. The Wordpress login/logout/registration links needed to direct users to the equivalent MediaWiki pages for those operations. If the user was already logged in, then they need to also be automatically logged in as the same user on Wordpress, and conversely, if the user is not logged in to MediaWiki then they should also not be logged in to the Wordpress.

This consists of two small scripts, Wordpress.php which is a small MediaWiki extension that provides an Ajax callback for getting user info for a passed user ID and token, and Wordpress-wp.php which goes at the end of the Wordpress wp-config.php file and checks the MediaWiki cookies to see if a user is logged in and if so checks via the MediaWiki Ajax callback if the cookie info is valid and if so creates and/or logs in the equivalent Wordpress user.

How it works

The idea is that the Wordpress checks on initialisation if there are any cookies present that represent a logged in user for the associated wiki - specifically a UserID and a Token cookie. The Token cookie is a unique character sequence which only exists if the user is currently logged in, and only lasts as long as the session after which time it's replaced by a new one.

If the Wordpress does not find any such cookies, it logs any currently logged in Wordpress user out and returns to allow normal anonymous browsing of the site.

If however a MediaWiki user ID and Token are found, then the code calls the MediaWiki Ajax handler (Wordpress::user) with these values (note that this request is not an Ajax request as it's being made by the Wordpress server-side PHP, not the client-side JavaScript like usual). The Ajax handler will check if the passed token matches the token for that user ID in the database, and if it does it returns the details for the user; their username, email address and a password to be used internally by the Wordpress (not the users MediaWiki password - the password is not really needed since normal Wordpress logins are disabled).

If the Ajax handler does not return any valid user then the cookie values were invalid and the result is the same as if there were no cookie values at all; i.e. any currently logged in Wordpress user is logged out, and the function returns allowing normal anonymous browsing of the Wordpress site.

If valid user information is returned, then first the Wordpress checks if it has an existing user of that name and if not it creates one using the information returned by the Ajax handler. It then makes either the existing user of that name or the newly created one the current user, logging out any currently logged in user if it was a different one first. And that's it for the Wordpress side.

The MediaWiki side consists only of the Ajax handler. An Ajax handler was used even though its not a true Ajax request because it's much lighter than processing a full MediaWiki page request. The handler simply receives a UserID and Token, creates a User object from the ID and checks if the User token matches the passed token to ensure there's no forgery going on. If there's a match it returns the information for the user in JSON format, or an empty JSON object if either there's not a match or the request did not derive from the local host.


This method requires that both the wiki and the Wordpress are running under the same domain so that the Wordpress is able to access the wikis cookies. If they were under different domains, then a client-side Ajax request to the wiki domain would need to be added to obtain the cookies.

Another minor issue is that for the returnto feature to work (allowing the browser to redirect back to the Wordpress after login, logout or registration) the following conditions must be met:

  • The Wordpress must reside in subdirectory under the MediaWiki installation
  • The wiki must be using short urls, e.g. http://domain/ArticleTitle
  • The Wordpress subdirectory must start with an uppercase letter (since the MediaWiki returnto value is treated as an article title)

If any of these are not the case, then the default code will not allow the returnto feature to work properly, but the code can be customised pretty easily to work with your setup, for example a simple redirect could be added into the wiki's LocalSettings.php.

Internationalisation (i18n)

Wordpress doesn't by default come with multilingual support, but it does have an internationalisation mechanism and many user-contributed translations of the interface messages in .mo files. I've installed the Wordpress Language plugin which allows for easy switching of language with a setting for the admin dashboard and the public site.

The single-signon solution above can be integrated with the wordpress internationalisation by passing the MediaWiki user's language selection along with the other info passed back by the Ajax handler, and then the Wordpress-wp.php script must set the WPLANG constant to this value.

One issue with this is that the WPLANG constant needs to be set prior to the inclusion of wp-settings.php, but all the calls to wordpress functions such as get_current_user_id() need to be called after the inclusion of wp-settings.php. But the $mwuser variable is required by both, so the script needs to be split into two parts. This can be done either by containing it all in a class and making $mwuser into a static class variable, or by making $mwuser a global.

The plugin does not come prepackaged with all the .mo files though (although there is a pay version that does), so the admin user needs to change to each of the languages manually from the dashboard to download the files if automatic language selection is wanted. The languages are not actually downloaded as files, the data is inserted directly into the wp_icl_strings and wp_icl_string_translations database tables.


Useful extensions

Online shop extensions


See also