Manual:Image administration/ru

Данная статья содержит сведения о том, как MediaWiki хранит файлы и о том, как настроить этот функционал.

Это относится к изображениям так же, как и к любым другим типам файлов, которые могут быть загружены (uploaded). Все файлы хранятся с соответствующей статьёй в пространстве имён "File:" ("Файл:"). MediaWiki до версии 1.14 использовали пространство имён "Image:" вместо "File:". "Image:" до сих пор поддерживается как псевдоним для обратной совместимости.

Загрузка и использование изображений
Смотрите: Help:Images

Включение функции загрузки файлов
Для загрузки файла должны совпасть три условия:


 * 1) Функция загрузки файлов в MediaWiki должна быть включена. Установите $wgEnableUploads в true.
 * 2) Тип файла должен быть разрешенным. Подробности: $wgFileExtensions.
 * 3) Пользователь должен входить в группу с правом "upload". По умолчанию это право дано всем авторизованным пользователям.

Загрузка файлов выполняется с помощью Special:Upload.

'Смотрите Manual:Configuring file uploads, Manual:Mime type detection'

Параметры, относящиеся к работе с файлами
Следующие параметры имеют отношения к функционалу работы с файлами:



Создание миниатюр изображений
Расширенный синтаксис изображений MediaWiki позволяет автоматически создавать миниатюры изображений (см. Manual:Configuring file uploads/ru по общей помощи по загрузке файлов).

функция создания миниатюр (Image thumbnailing) требует наличия ImageMagick или библиотеки GD. Рекомендуется использовать ImageMagick для получения миниатюр лучшего качества. GD анимированные GIF превращает в статические картинки. ImageMagick сохраняет анимацию GIF в миниатюрах. Загрузить ImageMagick можно с imagemagick.org. GD is included in some versions of PHP, and it is recommended to use GD on Windows systems. Библиотека GD доступна для загрузки с libgd.org.

В старых версиях МедиаВики (до 1.10.0) для того, что бы включить создание миниатюр, требуется установить $wgUseImageResize в true. В новых версиях этого не требуется. In newer versions this is not required.

Если вы используете ImageMagick, установите $wgUseImageMagick в true в файле LocalSettings.php. Убедитесь что $wgImageMagickConvertCommand указывает на абсолютное положение команды конвертации и что команда выполнима для веб-сервера. Включение ImageMagick вызывает ошибку:

To re-create old thumbnail files before you used ImageMagick you can use.

If rendering fails silently, check and increase.

GraphicsMagick can now also be used as an alternative to ImageMagick. You will need to set $wgImageMagickConvertCommand to the (absolute) location of the 'gm' command. E.g.:

$wgImageMagickConvertCommand = "/usr/bin/gm";

GIF
Для создания миниатюр для анимированных GIF-файлов ы среде Windows, вам потребуется установить ImageMagick согласно описанию выше.

SVG
MediaWiki поддерживает возможность рендеринга изображений в формате SVG: если такая возможность включена, изображения в формате SVG могут использоваться так же, как и любые другие — они будут автоматически растеризоваться и отображаться в виде файлов в формате PNG, с генерацией миниатюр «на лету», по мере необходимости. If you're on a shared host and no SVG renderer is pre-installed, you should probably ask your provider to install it for you.

Для включения поддержки SVG необходимо:


 * 1) Разрешите в LocalSettings.php возможность загрузки файлов SVG: $wgFileExtensions[] = 'svg'; Обратите внимание, что по соображениям безопасности MediaWiki откажется обрабатывать SVG-файлы, содержащие JavaScript.
 * 2) ːЧтобы избежать ложных срабатываний, установите $wgAllowTitlesInSVG = true;.
 * 3) ːЕсли вы получаете сообщение об ошибке, где говорится, что файл повреждён, убедитесь, что определение типа MIME работает нормально.
 * 4) Установите $wgSVGConverter, который вы хотите использовать для растеризации.
 * Можно выбирать из ImageMagick, sodipodi, inkscape, batik, rsvg, и imgserv.
 * For example: $wgSVGConverter = 'ImageMagick';
 * 1) * Если путь к выбранному программному конвертеру не содержится в переменной окружения system path, то нужно явно задать папку этой программы посредством параметра $wgSVGConverterPath.
 * 2) * librsvg быстр, но не очень аккуратен. Этот пакет включён в весьма сложную цепь зависимостей, в которой вы можете и не захотеть разбираться, если только у вас нет под рукой содержащего эту программу репозитория, который разрешит все эти зависимости за вас. Проекты Викимедиа используют rsvg 2.14. Note: As of version 2.22.3, there is a bug in locale handling (see Wikimedia bug report and GNOME bug report). Доступна заплатка для инструмента.
 * 3) * Batik обеспечивает наиболее точную отрисовку SVG среди доступных решений, хотя подчас недостаточно хорошо справляется со сглаживанием (anti-aliasing). У него более строгие правила разбора SVG, что заставляет его отвергать «почти правильные» SVG-файлы, принимаемые другими конвертерами (например, commons:File:UbuntuCoF.svg). Батик основан на Java, и гораздо медленнее, чем rsvg, хотя это не может быть большой проблемой, если только вы постоянно не добавляете SVG-файлы. См. сравнительные тесты SVG. Требуется много усилий, чтобы заставить его работать, если только он не входит в ваш дистрибутив.
 * 4) * Inkscape также не слишком аккуратно обрабатывает SVG-файлы, и примерно в два раза медленне, чем rsvg. При этом он был спроектирован для интерактивной работы с графигой, поэтому требует, чтобы у запускающего его пользователя была на сервере домашняя папка (home directory) с правами на запись. Поскольку он будет работать как пользователь www или кто-то подобный, он будет пытаться создать папки .inkscape/ и .gnome2/ в соответствующей домашней папке, и молча сломается, если это ему не удастся. Inkscape предпочтительнее, чем rsvg, в случаях (а) если используется среда Windows (если говорить об отдельном пакете) или (б) если у вас имеются важные SVG-файлы, нарисованные в Inkscape, которые некорректно обрабатываются в rsvg. Inkscape связан сложной цепью зависимостей с librsvg &mdash; используйте, только если эти компоненты есть в вашем дистрибутиве или доступны в качестве полностью автономного пакета.
 * 5) * Sodipodi — это ответвление от Inkscape. Применимо всё то же самое, что и к Inkscape. Sodipod в настоящее время активно не разрабатывается.
 * 6) * ImageMagick обрабатывает SVG-файлы, но с массой ошибок. Это значение по умолчанию, но избегайте его, если только это возможно. However, it does work. On Windows, $wgConvertPath must be set to avoid a conflict with Windows' own convert.exe. One simple alternative in this scenario is to add to LocalSettings.php the line, which also allows for spaces in the path.
 * 7) * The PHP Imagick extension supports SVG rendering, however the same considerations as for the regular ImageMagick apply.
 * 8) * Библиотека GD не способна преобразовывать изображения SVG в формат PNG, по крайней мере, согласно записи Джоя Асмуссена (Joen Asmussen) в блоге NoScope от июня 2008.
 * 9) * Многие современные веб-браузеры, за исключением Internet Explorer, умеют отображать файлы SVG напрямую — быстро, но неаккуратно (примерно так же, как ImageMagick). Использование librsvg для растенризации SVG и преобразования его в формат PNG даст гораздо более аккуратный результат. Прямое отображение SVG в MediaWiki по умолчанию не поддерживается.

Set $wgSVGConverter</tt> = false if SVG rendering is not needed and you wish to make your users download the svg file in order to view it.

JPEG (с использованием GD)
Об ошибках, связанных с созданием миниатюр JPEG-файлов, см.

For errors with JPEG thumbnails, see JPEG (using GD).

TIFF
Generating thumbnails of TIFF files requires MediaWiki 1.15.0 or newer.


 * 1) Allow upload of TIFF files in the LocalSettings.php file: $wgFileExtensions[] = 'tif';</tt>
 * 2) Add $wgTiffThumbnailType</tt> to LocalSettings.php and set to either jpg or png to specify which type of thumbnail you wish to have generated.
 * 3) Making thumbnails of TIFF files may require system resources beyond those needed for thumbnailing JPEG, GIF, or PNG files. Consider appropriate settings for $wgMaxImageArea</tt> and $wgMaxShellMemory</tt>

Deletion of images
Files, like wiki pages, can only be deleted by users with the " (delete)" permission ( by default). Deletion of files is done by deleting the associated description page (or by clicking the "" link in the "" table).

Deletion of individual revision
If a file has been altered, there is a revision history of the files which is displayed on the file article page. Each revision has a "" link. If this is clicked, the revision and the file are deleted.

The versions of files are separate from the page history of the file description page.

Information about old revisions of files are stored in the oldimage table while information on old revisions of the pages are stored in the Revision table.

Undeleting files
Before MediaWiki version 1.8, deleted images/files can not be undeleted (only the associated description page can be restored).

From MediaWiki version 1.8 up to 1.10, archiving deleted images/files (and thus undeleting them) is disabled per default, but can be enabled by setting $wgSaveDeletedFiles = true.

Since MediaWiki version 1.11, this is enabled per default, and $wgSaveDeletedFiles is deprecated. Instead, the behavior is controlled by $wgFileStore.

Information about deleted images are stored in the filearchive table.

Deletion of Archived Files
Since MediaWiki version 1.11, deleted images are still stored on the server by default. If you want to delete selected archived images, you can do so using the eraseArchivedFile.php maintenance script. If you want to delete all of them completely, you can do that with the deleteArchivedFiles.php script. If you delete archived files, you can not undelete those files anymore.

Reasons for Deleting a File
When choosing to delete a file, as described above, users will be asked to provide a reason for deletion. The available reasons can be edited on the MediaWiki:Filedelete-reason-dropdown of your wiki.

Data storage
Whenever an image is uploaded, several things are created:


 * 1) An article in the file namespace with the name of the file, e.g. File:MyPicture.png. This page is stored and can be edited like any other page.
 * 2) The file itself is stored in a folder on the file system.
 * 3) If necessary and thumbnailing is available, thumbnailed versions of the file will be created when necessary (such as for the usage on the file description page. These are stored in the thumb directory of the image directory, in a separate directory for each main file.

If $wgHashedUploadDirectory is enabled (by default), MediaWiki creates several subdirectories in the images directory.

The directory names are from the first two characters of the md5 hash of the final filename.

Folders
All image files are stored in a folder determined by $wgUploadPath (, by default).

Description of named image subfolders:


 * archive: This is the storage place for files that have been replaced by newer versions.
 * temp: used for temporary storage of files during image uploading. (Due to bug 9018, these files may not always be automatically deleted)
 * thumb: Thumbnails (automatically generated) for the files. If these are deleted, they are automatically regenerated when needed.

Depending on the configuration, there may be additional image subfolders:
 * math: Folder to store your rendered TeX input, see also Manual:Enable TeX or Math.
 * x/xy: If  is set to true (which is the default), images will be stored in subfolders of the images, thus making file paths look like  . See Manual:$wgHashedUploadDirectory for more details on why this might be desired and how this system works.

Database tables

 * The file description page is stored as any page in the page, text, revision etc. tables
 * image table: Holds some metadata such as the size of the file and the upload date.
 * oldimage table: This is stores information for files that have been replaced with newer versions.
 * filearchive table: holds the information on the deleted files.
 * imagelinks table: Records what pages use a file.

Space usage
Files need considerably more space than articles. The following calculations assume a block size of 4KB with Linux/Unix servers.

The default setting is $wgHashedUploadDirectory = true.

Space requirements for all directories:


 * image directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * archive directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * thumb directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB
 * temp directories: 0-f/x0-f: max. 16*16 = 256 directories = 256*4 KB = 1024 KB

Therefore, the basic amount of space needed without any images uploaded is 4 MB in theory (although the directories are created only when needed).

For each file we need:
 * size of the original image file + 2 KB average overhead

For files that need to be thumbnailed:
 * size of the created thumbnail(s) + 2 KB average overhead (each)
 * directory for thumbnail (4KB) (each image has its own thumbnail directory)

Examples:
 * image 20778 Byte png (small size, no thumb): 24 KB for the image: Total 24 KB
 * image 123.000 Byte jpeg (big size, auto thumb): 124 KB for the image, 4KB for the thumb directory, 64 KB for the thumb: Total: 192 KB

File Access
Uploaded files are generally served directly by the web server, not through MediaWiki. While there may be a minimal level of security through obscurity with path encryption (eg. /c/c4/...) if $wgHashedUploadDirectory is set, the path can be calculated easily from the file name and does not provide true protection.

For limiting access to authorized users, see Image Authorization

Licensing
A feature of MediaWiki allows the Special:Upload Page to streamline licensing of images. Wikipedia's Upload Page has a Licensing drop down box below image summary. This feature is turned off in default MediaWiki. To turn this feature on a sysop needs to edit Licenses in the MediaWiki namespace (example: MediaWiki:Licenses). S/he can do this by going to the MediaWiki:Licenses page of their wiki and clicking 'create' or 'edit'.

The page MediaWiki:Licenses expects a certain format in a wiki list.

Line 1 will produce "License text" and substitute the license 1 template in the image page and transclude license 2.

Line 2 will show a greyed out header with text "Header 1:"

Line 3 will produce "Attribution ShareAlike 2.5" and transclude template cc-by-sa-2.5 on the image page.

For detailed real world example, see Wikipedia:MediaWiki:Licenses or Commons:MediaWiki:Licenses.

Foreign Repositories
It is possible to access files stored in foreign repositories, without needing to upload them to the wiki, by setting the $wgForeignFileRepos array. This feature offers several possibilities:
 * ForeignAPIRepo accesses files from a remote MediaWiki installation, such as Wikimedia Commons, through its API
 * ForeignDBRepo accesses files through a database, and is useful for creating wiki families
 * FSRepo accesses files from a local folder

In all cases, one would be able to embed files into a page using ordinary image syntax and specifying the name of the file in the foreign repository. Note that some of the above implementations are still experimental, and might not be suitable for production sites.

MediaWiki Version
This applies to:
 * MediaWiki 1.9.x and above
 * other versions not verified