Samuel Richardson wrote: Images: If you have image uploads for each wiki, then you shouldn't symlink the images directories (and subdirs). Among other possible problems, you won't be able to deal with name clashes. If you only have uploads in a common wiki, then the images directories are not essential. On my wikis, I only have one common wiki for images so all wikis can share the same files. Root: Each wiki should have its own root directory - no symlink here. You'll need separate LocalSettings.php files as well as other files in the root. Maintenance: For convenience, it's easy to have a separate maintenance directory for each wiki. That allows for the scripts to find their own version of AdminSettings.php (in the root) and act "nicely" without having to resolve paths and such when you run a script. You can symlink the maintenance directory if you choose - there was a recent series of posts on this either here or on the msusers.com forum (can't remember). Others: You can symlink the other code directories. Mike

Eh? Where are you getting your information? Michael Daly wrote: We have the upload path and upload directory configuration variables for precisely those reasons. All you do is configure different paths for different wiki. There is no need to fiddle with symlinks or even multiple installations. There is no need to duplicate maintenance directories. We have had the --conf= and --aconf= parameters for ages, passing --conf= alone is normally enough as LocalSettings.php normally sets the $IP which is used to find the AdminSettings.php. And on top of that as of 1.13 we have native support for the MW_INSTALL_PATH environment variable. Just set that and there is absolutely no issue with finding the location of files.. The best way of hosting multiple wiki is using a single installation of MediaWiki, and testing the domain to determine what wiki to use config for. For command line stuff you can make your LocalSettings.php understand a environment variable, or find a way to pass a option argument specifying what wiki to use. Aside from that, I personally handle different versions of MW with different modifications because I do development. So I use a symlink based setup. AdminSettings.php extensions/ install-utils.inc profileinfo.php LocalSettings.php images/ languages/ redirect.php StartProfiler.php includes/ maintenance/ skins/ api.php index.php opensearch_desc.php thumb.php That's what my own install directories contain... Every last single one of those is a symlink. Half of them might not even be needed. The skins/ isn't used, images/ is a useless one as well, and there are symlinks to legacy scripts that mostly aren't needed. Personally, I use symlinks because it allows me to run different setups, different configurations, and such on different wiki. It's good for development, but wiki farming fits the single installation model best. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) ~Profile/Portfolio: http://nadir-seen-fire.com -The Nadir-Point Group (http://nadir-point.com) --It's Wiki-Tools subgroup (http://wiki-tools.com) --The ElectronicMe project (http://electronic-me.org) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) --Animepedia (http://anime.wikia.com) --Narutopedia (http://naruto.wikia.com)

On Sat, Sep 20, 2008 at 5:12 AM, Samuel Richardson <sam(a)richardson.co.nz>wrote;wrote: The "ultimate minimalist solution," as described in the wiki family article, has you just symlink the wiki directories of each site to the shared files: ln -s /home/user/public_html/example1.com/w /home/user/public_html/shared/w ln -s /home/user/public_html/example2.com/w /home/user/public_html/shared/w ln -s /home/user/public_html/example3.com/w /home/user/public_html/shared/w ln -s /home/user/public_html/example4.com/w /home/user/public_html/shared/w Then you would truly only need to update the files in one place. You might still need to run update.php 4 times, though, and that inconvenience alone might make another method better. You would also need to alias the images directories to avoid the issues Michael is talking about: In example1.com's vhost: Alias /w/images /home/user/images1 In example2.com's vhost: Alias /w/images /home/user/images2 and so on. I've used this method and it does work, though maybe it's overkill. :)