What did I want to say with such a scary headline?
In fact, everything is simple.
Suppose we have a domain in which we want to raise a bunch of wiki encyclopedias. For each individual wiki, we want a separate subdomain. But at the same time, we want all of this to work on a single code (so that in the event of an update we can change everything at once), and also that users have one registration in all our wikis.
')
In this article, I will discuss how to implement this using the mediawiki engine as an example.
Why is this necessary?
I will answer by example. I have a number of sites for different games. And I always wanted to have a single wiki resource for different games.
My script is:
- we have a single domain (in my case it is playwiki.ru )
- when entering it, we get to a certain main page of the project - a description of what it is, why, and of course - links to different wikis
- Each individual game wiki occupies its own subdomain: wow.playwiki.ru , diablo2.playwiki.ru , etc.
- Tables of users, groups - common to all sub-wikis, as well as cookies (i.e., once logged in, you remain logged in)
- common wiki engine code is used
- each wiki has its own database, its own image storage folder, its own skin and logo
Installing mediawiki.
So far, everything is simple. Install mediawiki as usual on your primary domain. No subtleties.
Server.
In my projects I use nginx. It is much faster than Apache, though a bit more complicated to set up.
In our case, we need the transition to any subdomain of our main domain to call the same code anyway. It is implemented simply:
server {
server_name playwiki.ru *.playwiki.ru;
root /wwwroot/playwiki.ru ;
index index.php;
}
Here it is worth noting that nginx has some difference in behavior from Apache. The fact is that no matter what subdomain you switch to, the server_name always opens first.
Therefore, in our case, peha will always receive “playwiki.ru” in
$ _SERVER ['SERVER_NAME'] , which will result in incorrect redirects in the mediawiki engine.
Immediately fix this bug:
In
LocalSettings.php at the very beginning we will write:
include ( 'My_ExtFunctions.php' );
$_SERVER[ 'SERVER_NAME' ] = ($pw_subdomain_prefix) ? $pw_subdomain_prefix . ".playwiki.ru" : "playwiki.ru" ;
At the end we will immediately connect our settings:
include ( 'My_LocalSettings.php' );
Here I also connected two files with my own settings, since I do not want to overload
LocalSettings.php .
$ pw_subdomain_prefix is installed inside
My_ExtFunctions.php :
function getMySubDomainPrefix() {
$a = $_SERVER[ 'HTTP_HOST' ];
$a = substr($a, 0, strpos($a, ".playwiki" ));
if ($a == 'www' ) $a = '' ;
// secure it!
$a = str_replace( "\t" , "" , str_replace( "\r" , "" , str_replace( "\n" , "" , $a)));
$a = str_replace( "*" , "" , str_replace( "'" , "" , str_replace( "\"" , "" , $a)));
$a = str_replace( " " , "" , str_replace( "," , "" , str_replace( "." , "" , $a)));
$a = str_replace( "/" , "" , str_replace( "//" , "" , str_replace( "\0" , "" , $a)));
return $a;
}
$pw_subdomain_prefix = getMySubDomainPrefix();
Set up mediawiki for subdomains.
So, we have the name of our subdomain in
$ pw_subdomain_prefix . All the code will be written in
My_LocalSettings.php .
Set the default skin:
$wgDefaultSkin = 'monobook' ;
Let the skins be searched in folders corresponding to the subdomain (for example, for wow.playwiki.ru, skins should be in the / skins / skin_wow / folder:
$wgStylePath = "{$wgScriptPath}/skins" . (($pw_subdomain_prefix == '' ) ? '' : "/skin_$pw_subdomain_prefix" );
$wgStyleDirectory = "{$IP}/skins" . (($pw_subdomain_prefix == '' ) ? '' : "/skin_$pw_subdomain_prefix" );
Let's make the database depend on the subdomain. In my case, the wiki on
www.playwiki.ru will use the “playwiki” base (it will also be the main storage for users, etc.), and the subdomain wiki will use the database such as playwiki_wow, playwiki_la2, etc.
if ($pw_subdomain_prefix) $pw_subdomain_prefix = '_' . $pw_subdomain_prefix;
$wgDBname = 'playwiki' . $pw_subdomain_prefix;
Setting common tables (users, ip lock):
$wgSharedDB = 'playwiki' ; // The $wgDBname for the wiki database holding the main user table
$wgSharedPrefix = 'wk_' ; // The $wgDBprefix for the database, if not used, this can be omitted
$wgSharedTables = array( 'user' , 'user_properties' , 'ipblocks' , 'user_groups' );
We set up a common domain for cookies so that the user logged in to any subdomain remains logged in to any subdomain:
$wgCookieDomain = '.playwiki.ru' ;
We make each wiki subdomain have its own logo:
$wgLogo = "images/logo$pw_subdomain_prefix.png" ;
Setting up upload'a images (in different folders):
$wgEnableUploads = true ;
$wgUploadDirectory = "images" ;
if ($pw_subdomain_prefix) $wgUploadDirectory .= "/img$pw_subdomain_prefix" ;
$wgUploadPath = "{$wgScriptPath}$wgUploadDirectory" ;
$wgUploadDirectory = "{$IP}/$wgUploadDirectory" ;
At the same time, we prohibit edits to non-logged users:
$wgGroupPermissions[ '*' ][ 'edit' ] = false ;
$wgGroupPermissions[ '*' ][ 'createpage' ] = false ;
$wgGroupPermissions[ '*' ][ 'createtalk' ] = false ;
$wgGroupPermissions[ 'user' ][ 'edit' ] = true ;
$wgGroupPermissions[ 'user' ][ 'createpage' ] = true ;
$wgGroupPermissions[ 'user' ][ 'createtalk' ] = true ;
$wgGroupPermissions[ 'sysop' ][ 'edit' ] = true ;
$wgGroupPermissions[ 'sysop' ][ 'createpage' ] = true ;
$wgGroupPermissions[ 'sysop' ][ 'createtalk' ] = true ;
$wgGroupPermissions[ 'bureaucrat' ][ 'edit' ] = true ;
$wgGroupPermissions[ 'bureaucrat' ][ 'createpage' ] = true ;
$wgGroupPermissions[ 'bureaucrat' ][ 'createtalk' ] = true ;
Reproduction of wiki encyclopedias.
Here everything is not very elegant.
After installing the wiki, I copied the base dump. Now, when I need to add a new wiki, I create (with handles) a new database, prescribe rights, and deploy this dump there.
In principle, it is tolerable. Given that the wiki is not planned to lift 10 pieces per day. :)