Manual:$wgForeignFileRepos

Properties required for all repos

 * class
 * The class name for the repository. May come from the core or an extension. The core repository classes are LocalRepo, ForeignDBRepo, FileRepo and ForeignAPIRepo.


 * name
 * A unique name for the repository.

For all core repos

 * url
 * Base public URL


 * thumbUrl
 * Base thumb url, if different from url/thumb


 * hashLevels
 * The number of directory levels for hash-based division of files


 * thumbScriptUrl
 * The URL for thumb.php (optional, not recommended)


 * transformVia404
 * Whether to skip media file transformation on parse and tp>Special:MyLanguage/Manual:thumb.php|rely on a 404 handler instead.


 * initialCapital
 * Equivalent to , determines whether file names implicitly start with a capital letter. The current implementation may give incorrect description page links when the local  and initialCapital are mismatched.


 * pathDisclosureProtection
 * May be 'paranoid' to remove all parameters from error messages, 'none' to leave the paths in unchanged, or 'simple' to replace paths with place holders. Default for LocalRepo is 'simple'. Note, some image thumbnailing software puts the thumbnail path into the resulting thumb's metadata, so this setting may not provide full protection.


 * descBaseUrl
 * URL of image description pages, e.g.


 * scriptDirUrl
 * URL of the MediaWiki installation, equivalent to , e.g.


 * articleUrl
 * Equivalent to , e.g.


 * fetchDescription
 * Fetch the text of the remote file description page. Equivalent to .


 * descriptionCacheExpiry
 * If set to 0, no caching will be used. Set to 1 or more (seconds) to define how long the local cache of description pages will last. Must set fetchDescription to true to use.

ForeignAPIRepo class

 * apibase
 * The base URL for the remote repository's API (e.g.  ). Only used for ForeignAPIRepo.


 * apiThumbCacheExpiry
 * How long to cache thumbs locally for. Setting this to 0 disables local thumb caching. Local thumb caching will reduce load on the foreign server, and improve user privacy. However it may cause your wiki to be slightly slower.

ForeignDBRepo class

 * directory
 * A path to MediaWiki's media directory local to the server, such as.


 * dbType, dbServer, dbUser, dbPassword, dbName, dbFlags
 * equivalent to the corresponding member of 


 * tablePrefix
 * Table prefix, the foreign wiki's </>


 * hasSharedCache
 * True if the wiki's shared cache is accessible via the local <tvar|wgMemc></>


 * favicon
 * A favicon for the remote repository

Default value (code in <tvar|Setup></>):

ForeignDBViaLBRepo class

 * wiki
 * wiki-db-name used in <tvar|LBFactoryConf></>

Directory permissions
You'll need rw on  and   for whatever user php runs as.

Using files from Wikimedia Commons : ForeignAPIRepo
You can set your wiki to use media from Wikimedia Commons (or from any other MediaWiki-powered site, see below) directly. However, please beware any legal implications.

To use this, you need:


 * PHP with JSON support (for the  function). JSON is enabled by default since PHP 5.2.0, you'll need the PECL extension for older versions. Since MediaWiki 1.16, this is no longer necessary; v. 1.16 will use custom (and slower) code if JSON is not available.
 * The remote wiki must also use MediaWiki 1.13 or later; otherwise its  returns <tvar|code> </> and file requests fail silently (i.e. the requested files are just treated as non-existent).
 * The remote wiki must also use MediaWiki 1.13 or later; otherwise its  returns <tvar|code> </> and file requests fail silently (i.e. the requested files are just treated as non-existent).

The code below enables media files from Wikimedia Commons on your site. You should place it in your "LocalSettings.php" file:

To pull images from another Wikimedia project, set <tvar|1> </> to this wiki's "<tvar|2>api.php</>" file like e.g. <tvar|3> </>. Example:

To embed an image in your installation, simply use.

Performance
You may need to configure the <tvar|1></> as well. Default it is set to <tvar|1>CACHE_NONE</>, meaning it will load the image from the remote host on each page load which will be very slow. Similarly, you need to set <tvar|1> </> to zero if you prefer to use the foreign thumbnails which will be faster.

Setting <tvar|1> </> may improve performance of instant commons at the cost of making images be lower quality on high resolution displays.

Currently MediaWiki does not support pipelining foreign api requests. A high performance site may want to look at setting up a local proxy (like nginx) that can coalesce multiple requests into a single pipelined request to reduce round trip times from TCP & TLS handshakes.

Using files from a database that you can access : ForeignDBRepo, ForeignDBViaLBRepo
The ForeignDBRepo class is very useful for creating wf>Special:MyLanguage/Manual:Wiki family</>|wiki families. In a wiki family, each wiki will have its own database or table prefix. Using this class, you can make a family member aware of the tables of another family member. Access through ForeignDBRepo is faster than through ForeignAPIRepo. This code should be deployed to LocalSettings.php.

Alternatively, if you have <tvar|lbfc></> set up for multiple wikis, you can use :

This needs not all the db* parameters as in.

Using files from a local folder : FileRepo
You can set your wiki to use media from a single folder. This is just a demonstration feature at present, and will probably be too slow for busy wikis or slow servers due to the lack of caching. This code should be added to LocalSettings.php.

The below code enabled media files from it:

Caveats
For optimal performance, use a wiki whose primary purpose is to serve as a commons as the target of. Avoid, for instance, pointing two content wikis at each other as foreign repositories in order to share files between them, because this will generate an excessive number of file requests on page views and edits as both wikis request the file from each other.

Likewise, avoid sharing a database between the commons wiki and other content wikis, especially if you must use  instead of   due to limitations imposed by your service provider or administrator. This generates a large number of potentially long-lived database connections that can result in impaired performance, or can exceed DB connection limits even on wikis with very little traffic or activity.