Manual:MediaWiki file usage

MediaWiki stores some data in the local filesystem. If you were to use webserver clustering to serve a big wiki, you'd want to take this into account.

User-accessible files

Uploaded media files

These go into a directory specified by LocalSettings.php, which is usually called "upload". Filenames are MD5-hashed, and since many filesystems don't handle large directories well, uploads are broken into subdirectories with the first and first two hex digits of the hash, e.g.:

Security note: Even though the upload system contains a filetype blacklist, you should ensure that your webserver is not configured to execute PHP or CGI scripts in the upload directory, just in case. Other filetypes may be unsafe downloads for some client systems.

Note. To add a direct link to a file you can use the following syntax:

{{filepath:file name}}

For example: {{filepath:Wiki.png}} → .

Archived uploads

When a new version of a file is uploaded, the old one is moved into the upload/archive directory, with its timestamp and "!" prepended. Again, hash subdirs are used:

upload/8/85/Edit_this_page_intl.png - current revision
upload/archive/8/85/20030628125544!Edit_this_page_intl.png - archived revision

Rasterized TeX

texvc generates rasterized PNG images from inline TeX code (if this option is enabled). These are dumped in a web-accessible LocalSettings.php-specified directory, usually called "math".

The filename is the hex MD5 hash of the normalized TeX input, plus ".png":

math/47e7849b634fe4487aaf981b32825e18.png

These files just accumulate, and are not automatically removed if the equations they represent are removed from articles (or existed only during preview rendering).

The images can be manually deleted, since the wiki can regenerate them, but if you do you'll want to fix the database as well:

Clear the affected entries in the math table, or the wiki will think it's already rendered those bits
- TODO: doublecheck that the file exists before deciding that an entry in the math table is valid
If using file caching, do one of the following to invalidate the cached pages or visits by anon users won't trigger regeneration of the images:
- remove all (affected) pages from the cache (consider grep)
- Update cur_touched fields to present time for affected entries (check for "<math>" in cur_text)
- Update the global $wgCacheEpoch timestamp in LocalSettings, forcing all cached pages to be regenerated without going to the bother of deleting anything.

Semi-private files

File cache

Optionally, rendered HTML pages may be kept in a cache directory and served to anonymous visitors. See more details at File cache.

Read-only lock file

The developer "Make database read-only" function writes a lock file, whose name and location may be specified in LocalSettings.php. If the file exists, the wiki will (hopefully) avoid operations which write to the database. The contents of the file are a message to be displayed to the poor users experiencing the editing lockout.

It need not be web-shared, but it shouldn't be a security risk to do so. The default location is in the upload directory.

TeX temporary files

TeX rendering requires a temporary directory to store intermediate files. It need not be web-shared, but it shouldn't be a security risk to do so. These files are only used during the course of producing the rasterized PNG files, and need not be kept or shared.

Private files

Debug log

One may optionally enable a debug log, which prints all kinds of annoying messages. It should not generally be left on, as this will waste time and space. The debug log includes URLs of all requests to the wiki and sometimes IP addresses, so you may not want to make it publicly available.

Session data

A little bit of data for login sessions is handled by PHP's session handling. This stores a bunch of small files in the /tmp directory; you can probably configure PHP to store them elsewhere.