Extension:SplitPrivateWiki
SplitPrivateWiki Release status: experimental |
|
---|---|
Implementation | User rights |
Description | Allows to setup 2 wikis a public and private but make them look like only one |
Author(s) | Brian Wolff (Bawolfftalk) |
Latest version | 0.2 |
MediaWiki | >= 1.35.3 |
Database changes | Yes |
License | GNU General Public License 2.0 or later |
Download | README |
|
|
Quarterly downloads | 0 |
Translate the SplitPrivateWiki extension if it is available at translatewiki.net | |
The SplitPrivateWiki extension allows you to make two wikis look like one. Certain namespaces will redirect to the other wiki (and vice versa). Additionally, any edits to the redirected namespace on the public wiki will automatically be transferred to the private wiki. This allows extensions like SemanticMediaWiki to use all the data from the public wiki in the private wiki, but when in the public wiki you can only use the public data. The idea being that one wiki is private and the other is public. This thus allows fine grained read access controls without some of the pitfalls common in other schemes. This extension is experimental. As always use at your own risk.
Installation
editWe assume you want two wikis run by same copy of mediawiki code, but using different virtual hosts or script paths (using things like alias/rewrite rules)
- Run the installer twice, once for the public wiki and once for the private wiki. For best security, have the installer create separate db users for each wiki
- Do not use the "LocalSettings.php" the installer generates, instead use a "LocalSettings.php" like:
<?php
wfLoadExtension( 'SplitPrivateWiki' );
SplitPrivateWiki::setup( [
'private' => [
'wgDBname' => 'secretwiki',
'wgDBuser' => 'secretwikiuser',
'wgDBpass' => 'secretwikipassword',
'wgSitename' => 'Secret',
'wgScriptPath' => '/secret',
'wgArticlePath' => '/secret/index.php?title=$1',
'wgExclusiveNamespaces' => [
NS_MAIN,
NS_TALK
],
],
'public' => [
'wgDBname' => 'publicwiki',
'wgDBuser' => 'publicwikiuser',
'wgDBpass' => 'publicwikipassword',
'wgSitename' => 'Public',
'wgScriptPath' => '/w',
'wgArticlePath' => '/w/index.php?title=$1',
'wgExclusiveNamespaces' => [
NS_HELP,
NS_HELP_TALK
],
],
'common' => [
'wgServer' => 'http://localhost:8080',
'wgShowExceptionDetails' => true,
'wgShowDBErrorBacktrace' => true,
'wgDBserver' => '127.0.0.1',
]
] );
// Extensions for both wikis
wfLoadExtension( 'foo' );
// If you want an extension on only one of the wikis
if ( $wgDBname === 'secretwiki' ) {
wfLoadExtension( 'Bar' );
}
- Changing the above of course to your specifics. It is important that either wgServer or wgScriptPath is different between the two wikis or else it won't be able to detect when you are in the secret wiki
- $wgExclusiveNamespaces should have the namespaces for each wiki that are exclusively handled by that wiki (and auto copied over to the other wiki). Do not include any namespaces here that are in $wgBuiltinNamespacesToRename. If you add custom namespaces you also have to add to wgExtraNamespaces.
- $wgBuiltinNamespacesToRename - contains a list of builtin namespaces that we want on both wikis, so that get renamed. e.g. MediaWiki becomes
MediaWiki_(Public)
. - You would probably want to change the various rights here so that only certain groups have read rights on the private wiki.
- Run
update.php --wiki=secretwiki
andupdate.php --wiki=publicwiki
Things should now just work.
Configuration parameters
editListed here are default values for config vars.
Namespaces handled exclusively on one wiki. Namespaces here will be autoredirected. Any namespaces here in the public wiki will be copied over to the private wiki.
$wgExclusiveNamespaces = [];
Namespaces to be in both and be renamed. Dummy versions of the renamed namespaces will be added on the other wiki to ensure redirects work. The public wiki will also have the renamed namespace copied over to the dummy version on the private wiki:
$wgBuiltinNamespacesToRename = [
NS_SPECIAL,
NS_USER,
NS_USER_TALK,
NS_CATEGORY,
NS_CATEGORY_TALK,
NS_MEDIAWIKI,
NS_MEDIAWIKI_TALK
];
Should sync edits show up in recentchanges (true = yes, false = no, 'bot' = show up but marked as bot). Note, currently this doesn't work with page deletions properly
$wgSplitWikiShowInRc = 'bot';
Notes
edit- For best security, the public wiki db user should not have access to the secret wiki db
- Use of different subdomains is reccomended for better isolation in case of XSS
- This extension was inspired by a conversation I had at EMWCon with Richard Evans.
Todo
edit- Make page deletions be bot edits
- Should also setup foreignFileRepoViaLB since this only copies page contents not files
- How user pages should work is kind of iffy, maybe it should be something like Extension:GlobalUserPage Allowing people to override, but copying a fake copy by default(?)
- Should set up single sign on automatically.
- page moves are kind of handled hackily
Bug reports and feature requests
editPlease report bugs and feature requests on the talk page.
See also
edit- Page import - overview of all page import tools