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:

OR
 * You use a different database for each wiki
 * 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: SamT
 * Used phpmyadmin to give all wiki type users full rights.
 * Did all the rest as in Linux box.
 * Reset all phpmyadmin rights.

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

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:

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?

Aren't instructions one and two the basically the same?
 * 1) Install MediaWiki and additional tools as usual
 * 2) Set up your wiki (e.g., MyWiki)

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) 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)

I thought the point was to use the "same source code"? I am creating new Mediawiki installs?
 * 1) Repeat the steps above for each wiki you wish to create, with suitable local setting files (e.g., anotherWikiLocalSettings.php, etc.)

Where does this LocalSettings.php file go?
 * 1) Create a LocalSettings.php file for your global settings, then select one from the two possibilities below:


 * 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!

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:

$sharedSourceDirectory = '/Path/to/root/of/yourwikipool'; $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:"; ... require_once( "$sharedSourceDirectory/extensions/ExtensionName/ExtensionName.php" ); ...
 * 1) This is the server's local file path
 * 1) This is the URL to the pool wiki
 * 1) For each extension named "ExtensionName" add one of these:

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?

Same question as above: Aren't instructions one and two the basically the same?
 * 1) Install MediaWiki and additional tools as usual
 * 2) Set up your wiki (e.g., MyWiki)

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

Same question as above: I thought the point was to use the "same source code"? I am creating new Mediawiki installs?
 * 1) Repeat the steps above for each wiki you wish to create, with suitable local setting files (e.g., anotherWikiLocalSettings.php, etc.)

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

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. 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: I was able to access the README files of teh wiki sites form the browser. I even was able to see the index.php.
 * the mediawiki, mediawiki/code and mediawiki/ 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,

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/ 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/ 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/ /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. Without this, I got a 404 Error because Apache was looking for  in the directory. 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: 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.
 * $wgSitename = "Wiki1"
 * $wgScriptPath = "/wiki1"
 * $wgDBname
 * $wgUploadDirectory = "{$IP}/images/wiki1";
 * $wgUploadPath = "{$wgScriptPath}/images/wiki1";
 * $wgLogo
 * $wgProxyKey

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:




 * 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:



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: 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: 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).
 * 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"

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  command line option for   to bypass the Composer checks in your environment. Somewhat like   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:


 * --Andreas P. Icon_External_Link_E-Mail.png 13:32, 12 January 2016 (UTC)
 * It possibly needs also  to be set. --Andreas P. Icon_External_Link_E-Mail.png 19:19, 4 February 2016 (UTC)

Multiple Repositories from different sites?
Is there a way to get the following working? 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 … then the files resolve only for repo1 but files from repo2 are not resolved at all and become red links. --Andreas P. 19:38, 4 February 2016 (UTC)
 * 1) local file reop
 * 2) shared file repo1 (via $wgForeignFileRepos)
 * 3) shared file repo2 (via $wgForeignFileRepos, e.g. commons repo see InstantCommons)
 * 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?
 * OK I can partly answer that:
 * 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.
 * 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 . This works now but does not work yet because of undefined headers in Cross Origin Resource Sharing (CORS).  --Andreas P. Icon_External_Link_E-Mail.png 02:28, 6 February 2016 (UTC)