Manual talk:Wiki family

Released to public domain

I'm the only author of the text, copied it from m:Help:Wiki family and hereby released it in the public domain... feel free to correct my English, if you find typos, weird wordings ;-) or syntax errors - everywhere … have fun, --Produnis 21:19, 20 April 2006 (UTC)

Install more than one wiki on the same server using one copy of MediaWiki

It is possible to install more than one wiki on a server provided that:

• You use a different database for each wiki

OR

• You use a different database prefix for each wiki (for Postgres, you can achieve a similar effect by using different schemas)

The goal is to share the same copy of the MediaWiki for all wikis, instead of duplicate it over and over. Here is what I did under Linux:

MyNewWiki=...

mkdir $MyNewWiki
cd $MyNewWiki
lndir ../mediawiki-1.9.3

rm LocalSettings.php

Then run the config script again to recreate LocalSettings.php file. Be sure to pick a new database, or give a different prefix from the first Wiki.

Finially, point the browser to the newly created, different wiki.

It seems to be running ok. However, maintenance/importTextFile.php will break (I'm looking into how to solved that right now. In the meantime, if you know the answer, please update):

A copy of your installation's LocalSettings.php
must exist in the source directory, and a correct copy of AdminSettings.php with the settings of the new database.

Scenario 2 does not work

If you set up all wikis like said, you have multiple sources. If you delete the sources but of one wiki, the other wikis do not work. You may edit the wiki2LocalSettings.php to match the correct path of the sources ($wgScriptPath), but then edit in wiki2 will edit the main wiki!

• I seem to be having the same problem. Has anyone found a solution to this?

Share media files and keep language descriptions

Is it possible to share image and media files in a common directory as described, but retain different language descriptions of the files (i.e. unique Image: and Media: pages), for each project in the family?

It doesn't specifically say so in this tutorial. I want our wiki to keep uploaded files to one place, but allow different image page descriptions for each wiki, AND still keep the same file revision history on each image page.

In other words, can an image used in one of the wikis link to a unique image page for this particular wiki, yet still utilize/share a common, shared file upload and file revision history? --Morten Blaabjerg 23:03, 29 April 2006 (UTC)

LocalSettings / AdminSettings

Description on how to best use common configuration files with small "exception" files per-installation would be useful. -- Sysy / ^(talk) 22:07, 9 May 2006 (UTC)

Image description

Question: I used the above method to fetch description from Commons, but it fetches the entire page, not just the "#Content" section; I get the action tabs, the left hand nav/tool panels, the style sheet, etc, and it looks realy horrible because it sticks all that inside the #Content section of the wiki I'm fetching from. Is this a bug, or did I do something wrong?

Hmmm... i don't know.. In my installed version, it all works fine that way... Maybe you miss-spelled the URL to Pool-Wikis images? --Produnis 16:50, 14 May 2006 (UTC)

Additional Wiki on same server

On a LINUX box I:

• created a fresh copy of the wiki files in a second directory
• ran the config script again then moved the newly created LocalSettings.php file
• was finished!

On a Windows XP machine I:

• Used phpmyadmin to give all wiki type users full rights.
• Did all the rest as in Linux box.
• Reset all phpmyadmin rights.

SamT

Note that I did NOT require an additional mySQL database. I DID create additional tables in the existing database. And I just gave those a different prefix from the first Wiki. And to address it, I have to point the browser to a different place inside my website.

Mark --24.195.14.18 03:09, 12 July 2006 (UTC)

So, it is not necessary to make an additional mySQL database, if you wish more than one Wiki in same hosting account. It´s optional. Read Help:FAQ#Installation_and_configuration

Shared image repository between different databases on different servers

Hi,

Im hosting my wikis with godaddy at the moment (i know its not the best host) using their economy plan.

I can create databases but every one is at a different url with different database name and database login.

Is there anyway to get the images and image description from the database on another server.

Cheers --158.125.9.4 16:16, 6 December 2006 (UTC)

Scenario 3: Thumbnail issue

Hi,

I followed scenario 3 for my multi-language wikis. At the moment, I've an english and a french wiki. All images go in the english one.

Everything works fine except when I try to create a thumbnail image from the french wiki:

[[Image:RnD_Geo_UseCase_MBorne.JPG|thumb]]

I get the following error:

Warning: mkdir() [function.mkdir]: $WIKI_HOME/fr/includes/GlobalFunctions.php on line 1534
Warning: imagecreatefromjpeg(/ecwiki/en/images/6/65/RnD_Geo_UseCase_MBorne.JPG) [function.imagecreatefromjpeg]: failed to open stream: No such file or directory in $WIKI_HOME/ecwiki/fr/includes/Image.php on line 1266
Warning: imagecopyresampled(): supplied argument is not a valid Image resource in $WIKI_HOME/fr/includes/Image.php on line 1274
Warning: imagejpeg() [function.imagejpeg]: Unable to open '/ecwiki/en/images/thumb/6/65/RnD_Geo_UseCase_MBorne.JPG/180px-RnD_Geo_UseCase_MBorne.JPG' for writing in $WIKI_HOME/fr/includes/Image.php on line 1310
Warning: imagedestroy(): supplied argument is not a valid Image resource in $WIKI_HOME/fr/includes/Image.php on line 1277

NB: The same operation from the english wiki works fine.

Thanks in advance for your help...

Scenario 3: Automatically mirroring all images between wikis?

I've set up scenario 3 on two domains on a Unix box using the same wiki source and now using interwiki links between two language versions, eg. example.com and example.de.

A problem I now have is having to upload the same images onto both domains to make them conveniently available directly within both wikis.

Rather than somehow setting up a shared image repository on a subdomain, such as pool.example.com, is there a way to make both wikis automatically share all images, regardless of which wiki they're uploaded onto?

In other words, if uploading an image on example.com, can it automatically be made available on example.de and vice versa? ..

... and for the relevant image description pages to automatically appear on both wikis, eg.:
example.com/wiki/File:Image.jpg
example.de/wiki/File:Image.jpg

As well as thumbnail listings of all images appearing on both domains at:
example.com/wiki/Special:NewFiles
example.de/wiki/Special:NewFiles

Has anyone done this before? If so, how would it best be set up? By somehow symlinking?

---

I am also having similar requirement and struggling to get it done. No help available over internet. Please advise.

# 2 Scenario 2: Quick set-up - Clarity please

You want to install more than one wiki on a single server, using the same source code, and using the same database?

1. Install MediaWiki and additional tools as usual
2. Set up your wiki (e.g., MyWiki)

Aren't instructions one and two the basically the same?

1. After successful installation, move LocalSettings.php into the root directory of your wiki and rename it in such a way to make it easy to track (e.g., myWikiLocalSettings.php)

So if I get this correctly http://www.foo.com/bubbawiki/ LocalSettings.php would go into "bubbawiki" 
if "bubbawiki" is where the wiki is installed. It is currently there (where I was told to
 put it in the set up of the wiki). Is the location different than the standard set up?

1. Repeat the steps above for each wiki you wish to create, with suitable local setting files (e.g., anotherWikiLocalSettings.php, etc.)

I thought the point was to use the "same source code"? I am creating new Mediawiki installs?

1. Create a LocalSettings.php file for your global settings, then select one from the two possibilities below:

Where does this LocalSettings.php file go? 

1. If your wikis are in different directories or subdomains linked to the same directory on your server, use this:

Where does the snip-it code go? 

I am sorry to come across so naive on this. But setting up a wiki farm would be great for 
what we are trying to do. I have been unsuccessful so far with these instructions 
and I am not PHP programming savant. Thanks!

I have to say that those instructions are better than the official ones. I'll try them. Thanks! -- Robert Abitbol

The "no extra files" solution

My solution requires not one additional file, and merely two symlinks.

I just symlink

radioscanningtw.jidanni.org -> mediawiki-1.10.0
taizhongbus.jidanni.org -> mediawiki-1.10.0

and in mediawiki-1.10.0/LocalSettings.php have this critical fork:

foreach(array('radioscanningtw','taizhongbus') as $v){
 if(strpos($_SERVER['SCRIPT_FILENAME'].$_SERVER['PWD'],$v)){
   $wgDBname=$wgSitename=$v; $wgLogo="/$v.png"; break;}}
$wgScriptPath="";

However I don't have any uploaded images etc. So I didn't test that. Jidanni 00:21, 4 June 2007 (UTC)

Scenario 4 - Common Skins and Extensions

If you want to share common skins and extension code so as to avoid duplication, you can simply do the following in each language's LocalSettings.php file:

#This is the server's local file path
$sharedSourceDirectory = '/Path/to/root/of/yourwikipool';
#This is the URL to the pool wiki
$sharedSourcePath      = 'http://pool.yourwiki.org';
...
$wgStylePath           = "$sharedSourcePath/skins";
$wgStyleDirectory      = "$sharedSourceDirectory/skins";
...
$wgSharedUploadPath      = "$sharedSourcePath/images";
$wgSharedUploadDirectory = "$sharedSourceDirectory/images/";
$wgUploadNavigationUrl   = "$sharedSourcePath/index.php/Special:Upload";
...
$wgRepositoryBaseUrl     = "$sharedSourcePath/index.php/Image:"; 
...
# For each extension named "ExtensionName" add one of these:
require_once( "$sharedSourceDirectory/extensions/ExtensionName/ExtensionName.php" );
...

Redundancy and confustion

Hi. This is a great article and very helpful, but some parts of it seem redundant or just unclear. For context, I program php full time.

1. "Scenario 1" doesn't seem to be a different scenario from 2 and 3, but just a link to a 3rd party recipe.
2. It's not clear at all what the difference is between the two code examples in Scenario 2. It seems like all cases of the second one would work in the first one, and also the non-domain parts of the logic are different, and it's not clear if that's a result of the history of this document, or if the examples are actually trying to illustrate different logic.
3. The introduction to Scenario 3 does not mention in any way, shape, or form, how it differs from Scenario 2, other than that it is "Drupal style". I don't know what that means. In fact, the introduction essentially states that it is exactly the same as Scenario 2.

If I was a better mediawiki hacker I'd try to fix this myself, but I thought I'd just throw in some feedback in case any mediawiki pros out there want to spiff up this document.

Thanks! John

Scenario2 and shared privacy-, disclaimer- and copyright-pages

We use Scenario2 with one installation and multiple configs and databases. Everything works fine, but we want to have only one privacy-, disclaimer- and copyright-page for all (sub)wikis together. does anybody know if there is something like

$wgRightsUrl ...

for the disclaimer- and the privacy-page? -- Jens 09.11.2007

Scenario 2: Quick set-up - Clarity please - Second Part of the story

You want to install more than one wiki on a single server, using the same source code, and using the same database?

1. Install MediaWiki and additional tools as usual
2. Set up your wiki (e.g., MyWiki)

 Same question as above: Aren't instructions one and two the basically the same?

Done, now I have something like
Serverside: www/MyWiki
With: www/MyWiki/config/LocalSettings.php

1. After successful installation, move LocalSettings.php into the root directory of your wiki and rename it in such a way to make it easy to track (e.g., myWikiLocalSettings.php)

Done, now I have something like
Serverside: www/MyWiki/MyWikiLocalSettings.php

1. Repeat the steps above for each wiki you wish to create, with suitable local setting files (e.g., anotherWikiLocalSettings.php, etc.)

Same question as above: I thought the point was to use the "same source code"? I am creating new Mediawiki installs?

Done, now I have something like
Serverside: www/MyWiki/MyWikiLocalSettings.php

And

Serverside: www/MyWiki/SecondMyWikiLocalSettings.php
Serverside: www/MyWiki/ThirdMyWikiLocalSettings.php

I have also

Serverside: www/MyWiki
Serverside: www/SecondMyWiki
Serverside: www/ThirdMyWiki

with the complete code inside of each. Have I missed the "delete some files" part?

1. Create a LocalSettings.php file for your global settings, then select one from the two possibilities below:

Done. Now I have a file named LocalSettings.php and inside I have

<?php

$callingurl = strtolower($_SERVER[' http://www.MyDomain.tld']);        // identify the asking url
        
if ( strpos( $callingurl, 'Mywiki') ) {
        require_once( 'MyWikiLocalSettings.php' );    
}
else if ( strpos( $callingurl, 'SecondMyWiki') ) {
        require_once( 'SecondMyWikiLocalSettings.php' );    
}
else if ( strpos( $callingurl, 'ThirdMyWiki') ) {
        require_once( 'ThirdMyWikiLocalSettings.php' );
}
?>

Now I put this into my "BaseWiki" e.g. MyWiki

Serverside: www/MyWiki/LocalSettings.php

Each Wiki is working as “stand alone”. I have tried this with Xampp

hxttp://localhost/www/Mywiki/index.php & hxttp://localhost/www/SecondMyWiki/index.php

are bringing up the startpage. But after renaming and moving the LocalSettings to the MyWiki file and creating the new LocalSettings I see only

Error, Setup.php must be included from the file scope, after DefaultSettings.php

Any help is appreciated.. but please remember the poor people who rend a hostingpakage and not a whole server. I have to work with (Fire)FTP and phpmyadmin

same error, not working

I followed scenario two, not working too, i get the same error when trying to open wiki root wiki/...and 404 when adding the specified uri, en for example..i wanted to note that you don't install more wikis, just one wiki source..when you rename your generated localsettings.php, you can install mediawiki again with different settings and create another settings file (which you rename and continue to make another)..when you finish, you just create the global LocalSettings.php which have the ettins the method mentions which is not working for me..but may be that is because i use lighttpd though i doubt it..--Alnokta 14:34, 26 December 2007 (UTC)

Problem with Upload

$wgUploadNavigationUrl = "http://www.mywiki.org/wiki/index.php/Special:Upload"; won't work if I set this value in a german wiki (de/) which should use the mainwiki's (wiki/) Upload folder. don't want to have to different image/ folders but all in the same wiki/image/. Spezial:Upload in the german wiki will lead on upload to a write error: The upload directory (public) is not writable by the webserver. Of course, since I did not give write permission on de/image/ but this proves that the german uploaddirectory is still being used, despite the config. 86.39.64.5 13:19, 2 March 2008 (UTC)

Database error

• A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "MediaWikiBagOStuff::_doquery". MySQL returned error "1205: Lock wait timeout exceeded; try restarting transaction (localhost)".

I get this error every 2days or so in my production system, running with mediawiki 1.19.2 and mysql 5.1.52, innodb_lock_wait_timeout set to 120s. What do we do to fix this permanently ? Is this a bug from mw ?

Easiest way

Why is this particular method not described on the main page? This method actually seems more completely described than any method actually given on the main page.

The easiest and imho the best way to do this (and has been for several years) :

• Create a unique domain name or subdomain for each wiki
• Create a database for each wiki
• Install one copy of Mediawiki and extensions (and probably a seperate copy purely to be used for running maintenance scripts) and point all subdomains to this folder in Apache
• Optionally share an uploads area
• Share the user database between wikis, using either the Mediawiki setting or by creating a SQL View
• Use the conditional logic provided overleaf to alter the settings for each wiki based on which wiki is being accessed

It really is that simple and works a treat.

I don't know if it's possible on Windows because I don't know if IIS can serve multiple named hostnames from one folder, but I imagine it can. If not, it is at the very least possible to share common settings on Windows by using a require_once directive to read in the common settings. --Kingboyk 12:41, 15 June 2008 (UTC)

Scenario 2 isn't written up very well, but it looks to me like your description is what they are essentially trying to describe.--180.148.77.14 08:40, 4 March 2012 (UTC)

Scenario 4: no thumbnails?

I've shared uploads and descriptions and all that detailed in scenario 4. I made the permissions on the /images directory in the repository all 777. However, when I use the following code I get an error instead of a thumbnail.

[[Image:pic.jpg|thumb|200px|description]]

ends up like:

Error creating thumbnail: Unable to create destination directory

It seems like it's permissions-related. Any ideas?

Drupal Scenario does not work

The drupal scenario looks rather clever, clean and flexible. My installation with several wikis now looks very clean and easy to understand and administrate. However, I get "Forbidden - You don't have permission to access / on this server." or "Forbidden - You do not have permission to access this document." when I try to access the new wikis after having followed closely the Drupal Scenario.

Here are things that I have tried out, which did however *not* solve the problem:

• the setup has a versioned mediawiki directory with the actual code (a), a softlink to it named code (b) and a directory (c) for the actual wiki(s) with softlink to b. As this did not work, I thought that this may be due to the too many (3) stages, so I tried to reduce these stages to 2 or one by directly softlink from c to a or to directly mention the (a) or (b) directory as virtual directories of the wiki domain in the apache config. All did not work (and of course I restarted apache2 all the time).
• I also tried to make sure that the user rights of the directories and softlinks were appropriate, again this did not help.
• As I thought that may be the problem lies in the flexible LocalSettings.php, I tried to just call a simple html-file or the README file to make sure that the problem was not related to php and php code. but I even got the rights problems when calling such non-php code (Even connected to simple setups like the one mentioned above).
• I should add that I tested the above scenario with latest Debian4, php 5.2, apache 2.2.

Has anyone ever tested it successfuly? The phrase "*should* now work" may indicate that this was not tested 1:1. So what is needed is more details in the explenation: what are the user and group rights/settings for each directory and link, how do you set up excactly the apache settings both for the mediawiki code directory, the mediawiki version directory and the actual wiki directory (Which is softlinkes/redirected to code which itself is again softlinked to the mediawiki version) etc...

Also, now the numbering of the scenarios has gone wrong, it seems we now have 2 (two!) scenarios both named "scenario 3", one of them being the Drupal Scenario.

Kai 91.62.106.57 22:16, 20 August 2008 (UTC)

Update (22 August 2008): These improvements helped:

• the mediawiki , mediawiki/code and mediawiki/<version> directories needed to have rights rx for all (owner, group and all). This helped a lot.
• when I combined this with directly accessing the /mediawiki/code directory in the apache configuration file,

I was able to access the README files of teh wiki sites form the browser. I even was able to see the index.php.

However, I now have a different (less dificult, I hope) problem: I now see the setup page of the wiki. This should not display as I have a proper LocalSettings.php in my code/<version> directory copied from Drupal-style LocalSettings.php )and changed the $confdir variable at the start of the file to point to my mediawiki directory) and I also have a LocalSettings.php in each /mediawiki/sites/<domain> directory.

From debugging the code, it seems that the code from Drupal-style LocalSettings.php is *NOT* able to locate the correct file from mediawiki/sites/<domain>/LocalSettings.php (where I use domain without www prefix and without port or directory, just simple e.g. en.mywiki.org or similar domain names). I tried both versions in the history of that file, one with for loop and one with while loop, but both end with no $conf variable set and so end with the setup dialogue from /includes/templates/NoLocalSettings.php

What finaly helped was to set safe_mode_gid=On (I have safe_mode=On), as the file_exist() function otherwise returned false. Now it seems to work...

I had the same problem of seeing the wiki setup page. However I discovered it was because I had mistakenly 'corrected' the code when the reason I wasn't seeing my wiki was something else. In other words, the Drupal code worked for me (as of 23 April 2010, using 1.15.3). If you think the problem is the Drupal algorithm, you could try the simplified code I have put in the talk page of Drupal-style local settings.

What was not in the Manual, and which I have now amended, is the need for an Apache virtual hosts alias such as Alias /mediawiki/code /home/web/mediawiki/code. Without this, I got a 404 Error because Apache was looking for index.php in the directory /mysite/mediawiki/code. I fixed the problem halfway when I applied the instructions for short URLs, but this gave me the wiki main page without the style sheets. The virtual hosts alias fixes both issues. Giles65 20:46, 23 April 2010 (UTC)

"Drupal-style" means what, exactly?

Can this section be retitled/rewritten to make sense for everybody that hasn't used Drupal before? This name is given as if it is self-explanatory, but it is not. ⇔ ChristTrekker 04:27, 13 November 2008 (UTC)

Absolutely this section does not seem to have nothing to do with Drupal and is certainly not self explanatory.Rather it should have mentioned about how drupal style is applicable in this context since drupal is one of the most popular open source CMS.

Ed

"Drupal-style" used in this context almost certainly refers to a rough equivalent of running multi-site Drupal. (See: "Run multiple sites from the same code base (multi-site)") --Davydog 19:54, 4 August 2011 (UTC)

Okay, but it has nothing to do with Drupal, really, and should be documented in the context of MediaWiki, not some random unrelated package. There's no need to mention Drupal except perhaps in passing ("..inspired by Drupal").--180.148.77.14 08:42, 4 March 2012 (UTC)

Multiple Wikis, one install/config

I need to host a reasonably small number of similar wikis. I want to be able to update the source and configuration for all of them simultaneously, and have simplified maintenance. The solution I came up with is inspired by http://www.steverumberg.com/wiki/index.php?title=WikiHelp_-_Method_One and especially the reader comment about mod_rewrite. I wrote it up so I could remember, and because I thought it might be helpful. Bryan C. 68.188.91.87 05:00, 19 December 2008 (UTC)

The general idea is that we use the web server (Apache, here) to set an environment variable based on the URL. Then, in LocalSettings.php, we include a file that depends on the environment variable and contains exactly those settings needed for the selected wiki. All other settings can be shared. I have separate image directories for each wiki - I suppose this would work with a shared images directory, but I haven't tried it.

Why this is good:

• Completely transparent to users
• Can make a config change to all wikis at once since they all share the bulk of LocalSettings.php. For example, you can add an extension to all of them as easily as for a single wiki. You can also make settings only on some wikis, or on all but some wikis.
• Avoids symbolic links, which will fail if the file structure of the MediaWiki install changes.
• No need to customize maintenance scripts - just set an environment variable to choose which wiki they effect.
• Only one directory needs to be backed up, and it's got everything.

Why you might try a different method:

• Don't have the ability to add RewriteRules to Apache
• Wikis will have widely differing settings/extensions.

This step-by-step shows how to set up a pair of wikis, which I'll call wiki1 and wiki2, and which are served at www.example.com/wiki1 and www.example.com/wiki2. I did this on Linux with Apache. The technique, but not the steps, should work in other settings.

Step 1: Create first wiki

In fact, I did this step a long time before moving to a multi-wiki setup. Just a normal install. If you plan to run multiple wikis under one database, you should use a different database prefix for each one.

Step 2: Add structure for separating wikis

Put a subdirectory structure on the images directory so that the images are stored in 'images/wiki1'. One way to do this is to rename images to wiki1, create a new directory images, copy wiki1 into it, then check that the permission settings are correct to allow write access by the webserver.

Split LocalSettings.php into two files, one still called "LocalSettings.php" and a second called "LocalSettings-wiki1.php". The -wiki1 file should contain only those settings which are specific to wiki1. For my setup, these were:

• $wgSitename = "Wiki1"
• $wgScriptPath = "/wiki1"
• $wgDBname
• $wgUploadDirectory = "{$IP}/images/wiki1";
• $wgUploadPath = "{$wgScriptPath}/images/wiki1";
• $wgLogo
• $wgProxyKey

Comments: Obviosly, you want different sitenames and possibly logos. The ScriptPath is so MediaWiki can generate pages with the correct URLs. For a single database solution, the DB variable could stay in LocalSettings.php and the site-specific file could set the prefix (mysql) or schema (postgres). The wgUpload variables set up the new images directory structure. I don't understand wgProxyKey, but I think it serves to keep a user's sessions untangled when they are logged in to multiple wikis.

Now add this to LocalSettings.php:

require_once("$IP/LocalSettings-".$_SERVER["WIKI"].".php");

It includes the "LocalSettings-????.php" file depending on the state of the environment variable WIKI. I put this immediately following the require_once for DefaultSettings.

Add this line to the Apache config file:

RewriteRule ^/wiki1(.*) /your/path/to/mediawiki$1 [E=WIKI:wiki1,last]

The E part sets the environment variable "WIKI" to wiki1. The rest of the line is fairly standard and could be changed if needed.

At this point, you should test your single wiki and make sure everything still works, especially image upload/view.

Step 3: Add additional wiki(s)

Create the database for the new wiki and grant appropriate permissions to the DBuser, as done in a standard install (or skip this if you're using prefixes).

Create the images/wiki2 directory and set it's permissions so the webserver can write it.

Add a RewriteRule to Apache. It's the same as above, except with wiki2 in both places instead of wiki1.

Move LocalSettings.php to a different name temporarily.

Allow write permission on the config directory.

Browse to www.example.com/wiki2. It should look just like the config for a fresh install. Fill in the install form, nothing special (except the database or prefix needs to be set appropriately for wiki2).

Put back your LocalSettings.php file that you hid temporarily.

Create LocalSettings-wiki2.php. Either hand-edit a copy of LocalSettings-wiki1.php, or cut the important stuff out of the newly created config/LocalSettings.php (which is then no longer needed).

Test wiki2. Repeat step 3 to add more wikis.

Maintenance

To run a maintenance script, simply set an environment variable to pick the target wiki. For example, under Linux:

WIKI=wiki1 php maintenance/checkUsernames.php

Could you elaborate on this ? How do you make use of the environment variable ? Last time I tried to use the update.php script, I screwed all of my wikis but one and had to reinstall all of them from scratch. Euloiix (talk) 18:41, 12 December 2012 (UTC)

Maintenance under Windows with symlinks

How can this be done under Windows running

• Link Shell Extension
• Xampp
• Wikifarm Alt. 2

Pretty simular environment as under linux.

I'm not sure if this is exactly what was being asked in this thread, but it took me awhile to figure out how to make maintenance scripts work with several symlinked wikis under Windows. The trick is to add "--conf C:/path/to/your/LocalSettings.php" to your command. So I just used ImportTextFile.php, with the following syntax:

php importTextFile.php --conf C:/xampp/htdocs/wiki/oso/LocalSettings.php --title "Test Page" --user Jamesmontalvo3 "C:/xampp/htdocs/wiki/import/ACU.wiki"

Without the "--conf C:/xampp/htdocs/wiki/oso/LocalSettings.php" it didn't work. Hope this helps.

--Jamesmontalvo3 (talk) 23:35, 2 October 2013 (UTC)

wiki family in PG

Seems that using schemas instead of table prefixes is the logical way of implementing a wiki family when using Postgres. I don't see any actual documentation for doing this, though. Am I just looking in the wrong place? Surely there's someone out there running more than one wiki on PG. ⇔ ChristTrekker 04:47, 7 January 2009 (UTC)

Wiki familly and shared social profils

Hi, we have a multi-langgage set of wiki and would like to install the extension SocialProfile with shared informations between wikis. Do you think it is possible?--Thibho 23:42, 23 January 2009 (UTC)

SocialProfile was poorly coded in respect to database calls (Table names are hard-coded into the queries). Because of this, it bypasses MediaWiki's shared table system. So, it is currently not possible to use SocialProfile with shared tables. --Cmelbye 23:28, 7 May 2009 (UTC)

Drupal Section

Thanks for updating that drupal part by giving a decent explanation which is self understandable

Ed

Modifying update.php

"You'll probably want to fix some scripts like maintenance/update.php so that you can specify a database name as a command line argument." Does anyone have any tips on how to do this? - Borofkin 22:58, 29 July 2009 (UTC)

$wgUploadNavigationUrl with $wgForeignFileRepos

I'm running MediaWiki 1.15.1 and created a pool (commons) for my wikis. It works great with $wgForeignFileRepos and a database connection. But I still have a big problem: I want to have the file-pages linked to the pool-Upload but $wgUploadNavigationUrl doesn't do anything. I still get the message "Upload disabled" in my language wikis. Anyone can help? --78.43.33.220 16:04, 15 October 2009 (UTC)

Hello. Did you defined

$wgEnableUploads       = true;

in every LocalSettings.php file of the language wikis? Greetings --Tlustulimu 22:03, 8 December 2009 (UTC)

Multiple Wiki's, Same Installtion, Same Database in Different Prefixes, but Sharing Same User Accounts?

Thanks for the Wiki Family idea which is working great for me. I am using the Method 2.

Now, my two wiki's are using the same MediaWiki source code, and they are using the same database with different table prefixes.

My question is ...

Can the two wiki's share the same user accounts, so that a user for the two wiki's just needs to create an account once, and doesn't need create an account for each wiki? Or, ...

Could I get the user account tables synced?

Any idea is greatly appreciated.--Ross Xu 17:10, 2 February 2010 (UTC)

Good question, I am also looking for my wikis to share the same user database. UPDATE: And here is the solution Manual:Shared database

Wikimedia Method

The method as actually used by the Wikimedia Foundation, creators of MediaWiki, should be much more explicitly documented to allow others to follow the precise method used by the Wikimedia Foundation on Wikipedia with links to the actual scripts used. Knowing the precise method used to create a wiki family of wikis localised in various languages in which each wiki is related to the other for alternate versions of the same page topics in different languages would be very instructive to others seeking a similarly scalable solution to creating multi-lingual wikis with full localisation.

Statements such as "You'll probably want to fix some scripts ..." without citing the actual working scripts as fixed for the purpose or diffs for what is needed are only a little better than no direction at all. Link to copies of the actual modified scripts to inform everyone precisely how this method can be implemented.

A branch of the MediaWiki Subversion code repository should be used at the very least to store copies of any files modified or added for Wikimedia implementations of MediaWiki.

Some comment about why mediawiki.org does not use a wiki farm for language localisation would be helpful.

Configuration isn't in SVN. You can view the configuration files here, but it can be pretty overwhelming. Reach Out to the Truth 01:44, 23 March 2010 (UTC)

Search Functionality

With any of these methods, will the search bar return pages across the entire wiki family? Or just whichever wiki instance you happen to have open when you plug in something to the search bar? If the former, is there any way to explicitly set it to only return pages from one branch?

I have the same question as above. I'd like to be able to search multiple wikis at the same time Bennylin (talk)

CentralAuth

There should be some mention of which scenarios work best with CentralAuth, right? Tisane 10:45, 27 May 2010 (UTC)

iw_prefix and iw_url

I'm new to MySQL. Where do I put the values of iw_prefix and iw_url? (Default? Length/Values? Somewhere else?) --83.255.135.251 22:16, 14 July 2010 (UTC)

Scenario 5: Image resize issue (solved, sideffect separate image language descriptions?)

Hi, I followed scenario 5 for my multi-language wikis. The idea was to create shared (pool), en, fr etc. wikis. All images go in the shared one (all separate databases).

Everything worked fine except resizing images when on en_wiki from shared_wiki and got errors similar to the below one:

[[Image:Image.jpg|100px|caption]]

Error creating thumbnail: convert: unable to open image `/home/[user]/shared/wiki/images//4/4d/Image.jpg': No such file or directory @ blob.c/OpenBlob/2480.
convert: missing an image filename `/home/[user]/shared/wiki/images//thumb/4/4d/Image.jpg/100px-Image.jpg' @ convert.c/ConvertImageCommand/2822.

I researched many sources, but nothing worked and don't remember which one to cite. But anyway, I have successfully used solution, which can be helpful.

Solution

$wgSharedTables[] = 'image';
$wgSharedTables[] = 'imagelinks';
$wgSharedTables[] = 'oldimage';

and link folder images from each wiki to shared/wiki/images

This solution doesn't just share all images through multiple language wikis, upload images just to shared wiki, but also allows to have wikitext for each image on every wiki separately, which is sideffect many people asked for (. I am right? Everything works smoothly so far. Rien Satori 07:20, 17 August 2010 (UTC)

To difficult for a noob

Is there then no easy possibility to provide 2 Wikis on a server which are absolutely independently of each other? 22:30, 3 November 2010 (UTC)

Separating images directories

What about mentioning that image directories should separated? I ran into this problem in Method 2. Configuration vars $wgUploadDirectory and $wgUploadPath should be changed. --Pintman 08:36, 11 August 2011 (UTC)

Shared File Repo with MW1.17

To those having problems getting shared images from their pool wiki, this link proved invaluable. Thread:Project:Support desk/$wgUseSharedUploads causes trouble 82.3.159.50 19:49, 17 October 2011 (UTC)

Make Multi Languages on Multi SubDomains

How Can I make Multi Languages on Multi Subdomains on this site: howiw.com

MediaWiki Symbolic Link 1.18.1 (Possible Method)

Some of the MediaWiki stuff is out of date. I was able to get a wikifamily/wikifarm running with the help of Freakolowsky and I wanted to help others get it running as well. Some of the Wiki Family instructions are similar but not exactly what I have. (Other stuff is old and doesn't work with current versions) It is also very rough as I am not an English major and I don't claim to be. If there is a better way to phrase something feel free to change and modify.

1. Download tarball from https://releases.wikimedia.org/mediawiki/1.18/mediawiki-1.18.1.tar.gz.

2. Extract tarball to web directory under directory structure desired.

3. Create a new folder with the name of the wiki you desire to create.

4. Inside of your new folder place config, images, and cache folders. This is to avoid overlapping with the other wiki.

5. Build a symbolic link between the extracted MediaWiki files and your new directory. It may throw an error because images, cache and config are created but this is fine.

Example:<br>
ln -s /webdir/mediawiki/mediawiki-1.18.1/* .

6. Begin the installation process by visiting the location of your desired wiki in a web browser.

7. Continue selecting settings in the installation until you are at the database portion of the install.

8. Select Oracle and select your TNS name.

9. Fill the new username and password in to create MW install and then click use a different username for DB access.

10. Fill the same username credentials into the new spot that appears. (If a new spot does not appear continue to the next step and then go back to the database step). (This was a bug and it may still be required I think it was fixed).

11. Finish the install just as you usually would.

12. Copy and paste the LocalSettings.php file in the root directory of your wiki install.

13. Check the LocalSettings.php $wgScriptPath variable and make sure that it is set to the wiki location and not the initial tarball of MediaWiki

14. Repeat steps 3 - 14 until you have created the desired number of MediaWiki installs.

15. Enjoy MediaWiki. :)

MediaWiki Family 1.19.0 (1 server, 1 codebase, 1 DB, shared hosting, htaccess, Short URL)

Desired System:

• 1 webserver, shared hosting, subdomains possible
• 1 file/codebase, easy maintenance/backup)
• 1 database, MySQL, using prefixes, easy backup
• .htaccess, Short URL like "/wiki1/Page_title"

Following Scenario 2: Quick set-up I was able to get possibility 1: "different subdomains that link to one directory on your server" to work. I had to move the codebase in a subdirectory and use a calling "directory (/wiki1/" to get everything to work (see Wiki in site root directory).

However I would prefer to use possibility 2: "wikis are in different directories (e.g. yourdomain.com/wiki1, yourdomain.com/wiki2 etc)" with Short URL (easier to setup new wikis and shorter URL like with subdomains). I was not able to symlink the sources (w1 -> w) like in the Note with my shared hosting (only .htaccess available). I'm searching for a solution and maybe will edit here. ChrisT 25 May 2012.

file in commons.wiki....org (=poolwiki) uploaded, file used in en.wiki.....org (language wiki)

works perfect but under the file in commons (=Poolwiki) in Special pages it says that "There are no pages that link to this file"! Any ideas? Donxello (talk) 02:42, 11 November 2013 (UTC)

It's normal. Try Extension:GlobalUsage if you want a way to know more. --Nemo 06:42, 11 November 2013 (UTC)

after installing multiple wikis via the second scenario the non-root wiki loads wrong mediawiki settings

I followed the instruction in the manual, and with some help from this discussion page and other stuff I found I managed to make things work. But - the second wiki (which does not seet in the root directory) is loading the wrong mediawiki name-space settings: it loads the first-wiki's css, and fails to load the sidebar settingd (leaving only the main page link, recent changes, random article and help) I guess I need to add some simple lines in localSettings I'm not aware of. Any idea?--Wess (talk) 15:03, 20 July 2014 (UTC)

Wikifarm upgrade testing to 1.25, problems with composer

We run http://biowikifarm.net successfully for a number of years using the symlink method and nginx. However, we now have problems with composer. composer.json and composer.lock were placed in the specific wiki folder (together with LocalSettings.php), which works for composer install/update. However, running update maintenance script in wiki farm style (sudo -u www-data php ./maintenance/update.php --quick --conf ./LocalSettings.php) results in "MediaWiki 1.25alpha Updater: Could not find composer.lock file. Have you run "composer install"?" The composer.lock is present in the specific wiki folder, but naturally not in the shared (target of symlinks) code folder. Anyone who already solved this? --G.Hagedorn (talk) 16:18, 28 February 2015 (UTC)

One thing you could try would be to use the --skip-external-dependencies command line option for update.php to bypass the Composer checks in your environment. Somewhat like --quick this option allows a knowledgeable administrator to bypass a default check.

--BDavis (WMF) (talk) 16:51, 28 February 2015 (UTC)

thanks, will try. I could run it with copying the files from one wiki to the symlinked shared folder as well, but this does not seem a safe solution. I am slightly worried about more problems downstream, if composer checks are ignoring the --conf location and defeat symlinks. --G.Hagedorn (talk) 23:58, 28 February 2015 (UTC)

Another possibility is to set the environmental variable MW_INSTALL_PATH and as far as I tested it $IP has to be defined as well. In LocalSettings.php I defined:

putenv ("MW_INSTALL_PATH=/path/to/wikiroot" );
if(getenv( 'MW_INSTALL_PATH' ) ) { 
  $IP = getenv( 'MW_INSTALL_PATH' );
} else {// __FILE__ or __DIR__ resolve symlinks but getcwd() does not
  /* getcwd() should evaluate to the most upper level from where all PHP scripts are parsed from, 
   * here it would be the wiki root: /path/to/wikiroot
   */
  $IP = getcwd( );
}

--Andreas P. 13:32, 12 January 2016 (UTC)

It possibly needs also $wgExtensionDirectory="/path/to/wiki/extensions"; to be set. --Andreas P. 19:19, 4 February 2016 (UTC)

Multiple Repositories from different sites?

Is there a way to get the following working?

1. local file reop
2. shared file repo1 (via $wgForeignFileRepos)
3. shared file repo2 (via $wgForeignFileRepos, e.g. commons repo see InstantCommons)

On MW 1.26.2 I get only 1 & 2 working but not all 1 & 2 & 3 together. If I set up repo1 and repo2 (=commons) twice via

$wgForeignFileRepos[] = array(
  'class' => 'ForeignAPIRepo',
  //…
);

… then the files resolve only for repo1 but files from repo2 are not resolved at all and become red links.

1. Any idea what I'm doing wrong ? (I did set up as well: $wgUseSharedUploads=true; $wgSharedUploadPath = '…'; $wgSharedUploadDBname="…"?
2. Can $wgForeignFileRepos set this up or do I need $wgLBFactoryConf?

--Andreas P. 19:38, 4 February 2016 (UTC)

OK I can partly answer that:

1. one part I missed is, setting up $wgUseSharedUploads, $wgSharedUploadPath, $wgSharedUploadDBname plus an identical repo1 via $wgForeignFileRepos defines the it twice – not a good solution, the resolving might become confuse somehow.
2. Another part is that an MW 1.20 api and MW 1.26 api appear not working well together, especially when you have al kinds of media (*.ogg, mp3 etc). I had to switch to ForeignDBViaLBRepo with a defined $wgLBFactoryConf . This works now but Extension:MultimediaViewer does not work yet because of undefined headers in Cross Origin Resource Sharing (CORS). --Andreas P. 02:28, 6 February 2016 (UTC)

For "Multiple Wikis Sharing Same Resources", Shall we delete the replaced folders after redirecting them to the "pool"?

Referring to the instruction here.

After replacing the directories as per the instructions, do we then delete the directories from the other installations, and only leave the directories in the "pool" installation? Or just leave them but upload all the extensions to the the "pool" installation? The manual does not elaborate on this point.

Thanks.

Do users have to register in every wiki separately?

Referring to the option of "Multiple Wikis sharing same resources", or "Giant switch" method.

Will users be required to register in every wiki separately? or there is a way to register in the entire network?

Also, if these two methods don't have this option, are there any other methods that provide this functionality?

Thanks.

— Preceding unsigned comment added by Atef81 (talk • contribs) 05:37, 19 April 2017

@Atef81: You can set up $wgSharedDB, which by default will share users and user preferences between wikis (you can cusomize what tables are shared with $wgSharedTables). You can share these things regardless of whether your wikis are set up as a farm with a shared codebase or are installed separately. Sam Wilson 10:58, 5 March 2018 (UTC)

Is it possible to have multiple wikis separated by folders and subfolders?

I'm thinking of something like:

wiki/ (wiki pool)

wiki/project

wiki/project/lang

wiki/project2

wiki/project2/lang

So that I wish to have multiple projects sharing the same user login, etc. What approach should I have to do it? Is it too dumb to use the same domain?

— Preceding unsigned comment added by 179.176.114.181 (talk • contribs) 20:29, 30 July 2017

Yes, this is not too hard, and not dumb at all (I think). You'd start by making aliases of each of those paths to wherever MediaWiki is installed (e.g. /var/lib/mediawiki) and then in your LocalSettings.php you'd have to set up the mapping of these to a 'wiki ident' (which in maintenance scripts is set as the MW_DB constant. Then, you'd set all the different configuration variables, as described in Manual:Wiki_family#Basic_principles. To share user info, you'd set up $wgSharedTables for the user, user_options, etc. tables. Sam Wilson 00:32, 31 July 2017 (UTC)

I've added an example of a subdir to the docs. Sam Wilson 01:20, 31 July 2017 (UTC)

Unhelpful

This is confusing and hard as hell. You are making non-programmers' lives harder. --Zerabat (talk) 18:27, 1 March 2018 (UTC)

@Zerabat: I quite agree that this page is super-confusing at the moment! Sorry. :-( Does the 'Basic principles' section make sense? Further down there's plenty of contradictory stuff. What set up are you aiming for (separate domains, subdirectories, versions, etc.)? I'm not au fait with all of this, but can certainly try to help! Sam Wilson 23:34, 1 March 2018 (UTC)

I was trying to set up a local wikifarm just for testing purposes, but I got lost. --Zerabat (talk) 01:04, 2 March 2018 (UTC)

@Zerabat: For local testing, I usually set up symlinks to from e.g. wiki1/ and wiki2/ directories to mediawiki/, and use the following in LocalSettings.php:

if ( defined( 'MW_DB' ) ) {
	// Command-line mode and maintenance scripts (e.g. update.php) 
	$wikiId = MW_DB;
} else {
	// Web server.
	$wikiId = basename( dirname( $_SERVER['SCRIPT_NAME'] ) );
}
$wgSitename = "Dev Wiki " . $wikiId;
$wgScriptPath = "/" . $wikiId;
$wgDBname = "mediawiki_" . $wikiId;

It's clunky and doesn't do anything with URL rewriting or anything, but works fine.

In general though, you're right this page needs to be better. I think subpages for each type of configuration might be good.

Sam Wilson 01:43, 2 March 2018 (UTC)

@Sam Wilson Thank you for the above! I have just set up my first wiki family however at first the login wasn't working because the script path was always the same, thus it couldn't be used to determine the right instance. After setting $wgScriptPath to "/" . $wikiID; it works like a charm. Thank you! :-) Devaroo (talk) 23:34, 23 January 2024 (UTC)

Organisation of this page

I've started a thread over on MediaWiki-Discourse about the general organisation of this page: https://discourse-mediawiki.wmflabs.org/t/wiki-farm-documentation/316 (I've started it there cause I think it'll get seen by more people). Sam Wilson 10:59, 5 March 2018 (UTC)

Merge wiki family into one wiki

Years ago we decided to create a wiki family (like Wikipedia and Commons):

1. text wiki with locked namespace File:
2. media wiki with files

Now this is not necessary anymore, and with the next upgrade we want to merge these two wikis into one. Are there any experiences from other wiki administrators, which could help us to do this smoothly? Thanks in advance for any hints, recipes, and advice. --ThT (talk) 09:23, 12 April 2019 (UTC)

I'm probably going to merge two wikis into one later this year. I think the best option is the Import/Export version explained on Manual:Merging_a_wiki_into_another_wiki. Presuming you've used the same user database for both sites, it should be straightforward? NemesisAT (talk) 12:12, 27 June 2019 (UTC)

wiki farms

• Hi, how can i set up mediawiki farm in my vps?--Msnhinet8 (talk) 01:06, 9 October 2019 (UTC)
  • @Msnhinet8: How familiar are you with MediaWiki and server configuration? Do you have a single wiki running already? The Basic principles section sets out the minimum things you need to sort out for a wiki farm. Have you read it and do you have any particular questions? Sam Wilson 01:15, 9 October 2019 (UTC)
• Yes, so you can install mediawiki farm?--Msnhinet8 (talk) 01:34, 9 October 2019 (UTC)
• can you help me?--Msnhinet8 (talk) 01:34, 9 October 2019 (UTC)
  • @Msnhinet8: It is possible to install a wiki family on a VPS, yes. I and others are very willing to help you, but we can't do it for you. :-) Do you have any specific questions? You might also be interested in asking on Wikimedia Developer Support (where your questions may get more vibility than here). Sam Wilson 03:06, 9 October 2019 (UTC)
• i can send your e-mail my vps account and pass.--Msnhinet8 (talk) 03:11, 9 October 2019 (UTC)
• beacuse i want to build a only taiwanese create wiki mediawiki farm.--Msnhinet8 (talk) 03:11, 9 October 2019 (UTC)

out-dated link

"Ubuntuguide.org MediaWiki tips" doesnt exist anymore. Maybe link to archive.org? https://web.archive.org/web/20170712122500/http://ubuntuguide.org/wiki/MediaWiki_tips

Done. Thanks for noting! Cheers --[[kgh]] (talk) 09:53, 3 March 2021 (UTC)

Final and very important step on $wgServer

Mediawiki installation rewrite the servername at address bar upon every page loading, so please be make sure that $wgServer at LocalSettings.php is set to your actual base URL:PORT and not to http://localhost:80 (unless you actually want to only access MediaWiki through your localhost). Otherwise links will not work, especially in the case of local wiki-farm setup with virtual hostings. It requires each servername with allocated port address as URL:PORT format on its respective LocalSettings.php files.

A better way to give instructions

Honestly, the procedures are not well explained.

How about we work on a better presentation?

So let's start:

1. Create subdirectories like Wikipedia has done. Ex: en.wikipedia.org
2. In each subdirectory, install a wiki
3. And then what?

Starting off with a summary of the different approaches and identifying the key/fundamental elements of each approach, probably in a table, would help greatly, I think. For the inexperienced there are too many concepts involved that are mostly not well-explained and not clearly or accurately expressed making it very difficult to draw the relevant information from this page as it stands. --Wsierke (talk) 05:37, 22 December 2021 (UTC)

How to upgrade with global LocalSettings

php update.php --conf ../LocalSettings_shoopz_com.php

Using this method to upgrade doesn't work if I'm using LocalSettings.php for global settings? 84.50.163.172 19:56, 14 March 2022 (UTC)

Use php update.php --wiki shoopz instead. I've updated the page to no longer suggest using individual overrides files directly, which indeed often doesn't work. Krinkle (talk) 20:51, 3 April 2022 (UTC)

Switch statement section

Why was the giant switch statement section removed? 2001:7D0:8440:C080:8885:6C6C:818:34C3 17:04, 23 April 2022 (UTC)

It was by far the easiest and most convenient way to setup a wiki farm, so I congratulate the person who took it upon themselves to remove it. 2001:7D0:8440:C080:8885:6C6C:818:34C3 17:07, 23 April 2022 (UTC)

It was simplified as Manual:Wiki family#Separate_settings_files by Special:Diff/5145587. The switch statement as previously documented was unnecessarily complicated. -- BDavis (WMF) (talk) 17:25, 23 April 2022 (UTC)

FIle usage display at wiki family

I have set to keep all files at my wiki family like files.mywiki.org

So I see that File usage is not shown globally. How can I set this option? Fokebox (talk) 10:41, 24 June 2022 (UTC)

Including wiki localsettings_wikiID.php fix

$_SERVER['SERVER_NAME'] should be replaced with strtolower($_SERVER['SERVER_NAME']) to ensure the includes work correctly.

<?php
$wikis = [
    'example.org' => 'examplewiki',
    'one.example.org' => 'onewiki',
];
if ( defined( 'MW_DB' ) ) {
    // Automatically set from --wiki option to maintenance scripts
    $wikiID = MW_DB;
} else {
    // Use MW_DB environment variable or map the domain name
    $wikiID = $_SERVER['MW_DB'] ?? $wikis[ strtolower($_SERVER['SERVER_NAME']) ?? '' ] ?? null;
}

if ( $wikiID ) {
    require_once "LocalSettings_$wikiID.php";
} else {
    die( 'Unknown wiki.' );
}

// Add any settings that should apply to all wikis below this line

Mbbava (talk) 22:52, 17 August 2022 (UTC)

Improve docs about adding new wikis

The first approach concludes with "To create a new wiki, create its database and add its settings first, and then run php maintenance/update.php --wiki=mywiki.".

This could use a good deal of clarification. The database not only needs to exist but it also requires tables to be set up. To 'create' the existing database with its schema, I imagine you would need to either run install.php through the CLI or use the web updater. Somewhat confusingly, this creates a LocalSettings.php even if you already added the settings, but you may still need it for the secret key and upgrade key that get generated. I'm guessing those keys must be unique to each individual wiki, but please correct if I'm wrong. I expected the CLI script to be an equal if not better alternative but I may missing something :

• I tried using install.php several times, but it always exits with "The environment has been checked. You can install MediaWiki. No wiki found". Incidentally, in order not to accidentally overwrite the existing LocalSettings.php file, it seems best to set a different path to --confpath. Again something on which our documentation could shed some light.
• After a while, I gave up and used the web updater: the database was initialised successfully and a LocalSettings file was downloaded to the computer. Unlike install.php, the web-based config script detects if there is a LocalSettings.php and lets you add an upgrade key, which I added to a separate settings file for the new wiki. I also copied the secret key to the wiki-specific settings.

I'm sure others will have more experience setting up and maintaining wiki farms/families, so I hope we can start improving the documentation. Can we use install.php to create additional wikis and if so, how? Which flags/settings to use, etc. What about the LocalSettings.php file? What about the keys? Cavila 07:35, 6 July 2024 (UTC)

To be honest, I don't know what the upgrade key is used for. But I use the same key for the entire wiki family.

I once merged four language versions into one wiki family and still have difficulties with the images. Each language version has its own images and then there is a Commons wiki for media. I can't get the language versions to see both their own images and the Commons images in the configuration. I therefore continue to run Commons as a separate installation.

To your questions:

I also think the documentation is completely inadequate and I still don't understand it.

I have decided to create a separate database for language versions. I initially fill this via the web installation. But then I throw away the offered LocalSettings.php file and add another switch branch in my own LocalSettings.php file. WikiForMen (talk) 15:58, 6 July 2024 (UTC)

Yes, about the documentation in general, it is in quite a state and the 'three methods' structure is misleading in addition to being confusing. I actually started rewriting it on my own and intend to pick up where I left sooner or later. Cavila 11:20, 8 July 2024 (UTC)