Manual:Image administration/ru
Данная статья содержит сведения о том, как MediaWiki хранит файлы и о том, как настроить этот функционал.
Это относится к изображениям так же, как и к любым другим типам файлов, которые могут быть загружены (uploaded). Все файлы хранятся с соответствующей статьёй в пространстве имён "File:" ("Файл:"). MediaWiki до версии 1.14 использовали пространство имён "Image:" вместо "File:". "Image:" до сих пор поддерживается как псевдоним для обратной совместимости.
Загрузка и использование изображений
Включение функции загрузки файлов
Для загрузки файла должны совпасть три условия:
- Функция загрузки файлов в MediaWiki должна быть включена. Установите для $wgEnableUploads значение
true
. - Тип файла должен быть разрешённым. Подробности: $wgFileExtensions .
- Участник должен входить в группу с правом «upload». По умолчанию это право дано всем авторизованным участникам.
Загрузка файлов выполняется посредством служебной страницы Special:Upload.
См. Руководство:Настройка загрузки файлов , Manual:Определение типа MIME и Manual:Adding support for new filetypes
Параметры, относящиеся к работе с файлами
Следующие параметры имеют отношения к функционалу работы с файлами:
Создание миниатюр изображений
Синтаксис изображений MediaWiki позволяет динамически изменять размер c миниатюры изображений (см. Руководство:Настройка загрузки файлов по общей помощи по загрузке файлов).
Функция создания миниатюр (Image thumbnailing) требует наличия ImageMagick или библиотеки GD - ни один из этих продуктов не входит в дистрибутив MediaWiki по умолчанию.
GD
PHP поставляется с графической библиотекой GD, включенной по умолчанию. GD не потребует какой-либо настройки или модификации.
В системах Windows рекомендуется использовать GD.
GD можно скачать в https://libgd.github.io/. В последних PHP версиях этого не требуется.
ImageMagick
В MediaWiki включите ImageMagick в LocalSettings.php
, установив для $wgUseImageMagick значение true
.
ImageMagick можно скачать в https://imagemagick.org/.
После установки ImageMagick вы должны включить ImageMagick и указать MediaWiki на программу convert
или convert.exe
на вашем компьютере в LocalSettings.php вот так:
$wgUseImageMagick = true;
#$wgImageMagickConvertCommand = 'C:/ImageMagick/convert.exe'; # for Windows
$wgImageMagickConvertCommand = '/usr/bin/convert'; # for Linux
Если вы используете ImageMagick, установите $wgUseImageMagick в true
в LocalSettings.php.
Убедитесь, что команда может быть выполнена процессом веб-сервера.
К примеру, пользователи ОС Windows могут захотеть изменить значение по умолчанию на «C:\ImageMagick\convert.exe» (или что-то подобное).
Для воссоздания старых файлов миниатюр перед использованием ImageMagick вы можете использовать $wgThumbnailEpoch .
Если рендеринг завершается неудачно, проверьте и увеличьте значение $wgMaxShellMemory .
GraphicsMagick также можно использовать в качестве альтернативы ImageMagick. Вам нужно будет установить $wgCustomConvertCommand на следующее. Например:
$wgUseImageMagick = false;
$wgCustomConvertCommand = "gm convert %s -resize %wx%h %d";
Форматы изображений
GIF
Для создания миниатюр для анимированных GIF-файлов в среде Windows, вам потребуется установить ImageMagick согласно описанию выше.
SVG
MediaWiki поддерживает возможность рендеринга изображений в формате SVG: если такая возможность включена, изображения в формате SVG могут использоваться так же, как и любые другие — они будут автоматически растеризоваться и отображаться в виде файлов в формате PNG, с генерацией миниатюр «на лету», по мере необходимости. Если вы используете общий хост и не предустановлен SVG-рендер, вам, вероятно, следует попросить вашего провайдера установить его для вас.
Для включения поддержки SVG необходимо:
- Разрешите в LocalSettings.php возможность загрузки файлов SVG:
$wgFileExtensions [] = 'svg';
Обратите внимание, что по соображениям безопасности MediaWiki откажется обрабатывать SVG-файлы, содержащие JavaScript.
- ːЕсли вы получаете сообщение об ошибке, где говорится, что файл повреждён, убедитесь, что определение типа MIME работает нормально.
- Добавьте
$wgSVGConverter
в файл LocalSettings.php и выберите инструмент, который вы хотите использовать для растеризации.- Можно выбирать из ImageMagick, ImagickExt, sodipodi, inkscape, batik, rsvg, и imgserv.
- Например:
$wgSVGConverter = 'ImageMagick';
- Если путь к выбранному программному конвертеру не содержится в переменной окружения system path, то нужно явно задать папку этой программы посредством параметра
$wgSVGConverterPath
.. - librsvg быстр, но не очень аккуратен. Это зависит от большого количества библиотек. Чтобы автоматически установить все эти библиотеки, вы можете использовать менеджер пакетов. Проекты Викимедиа используют rsvg.
- Batik обеспечивает наиболее точную отрисовку SVG среди доступных решений, хотя подчас недостаточно хорошо справляется со сглаживанием (anti-aliasing). У него более строгие правила разбора SVG, что заставляет его отвергать «почти правильные» SVG-файлы, принимаемые другими конвертерами (например, commons:File:UbuntuCoF.svg). Батик основан на Java, и гораздо медленнее, чем rsvg, хотя это не может быть большой проблемой, если только вы постоянно не добавляете SVG-файлы. См. сравнительные тесты SVG. Требуется много усилий, чтобы заставить его работать, если только он не входит в ваш дистрибутив.
- Inkscape также не слишком аккуратно обрабатывает SVG-файлы, и примерно в два раза медленне, чем rsvg. При этом он был спроектирован для интерактивной работы с графигой, поэтому требует, чтобы у запускающего его пользователя была на сервере домашняя папка (home directory) с правами на запись. Поскольку он будет работать как пользователь
www
или кто-то подобный, он будет пытаться создать папки.inkscape/
и.gnome2/
в соответствующей домашней папке, и молча сломается, если это ему не удастся. Inkscape предпочтительнее, чем rsvg, в случаях (а) если используется среда Windows (если говорить об отдельном пакете) или (б) если у вас имеются важные SVG-файлы, нарисованные в Inkscape, которые некорректно обрабатываются в rsvg. Inkscape связан сложной цепью зависимостей с librsvg — используйте, только если эти компоненты есть в вашем дистрибутиве или доступны в качестве полностью автономного пакета. - Sodipodi — это ответвление от Inkscape. Применимо всё то же самое, что и к Inkscape. Sodipod в настоящее время активно не разрабатывается.
- ImageMagick обрабатывает SVG-файлы, но с массой ошибок. Это значение по умолчанию, но избегайте его, если только это возможно. Тем не менее, это работает. В Windows необходимо установить $wgConvertPath, чтобы избежать конфликта с convert.exe. Одной из простых альтернатив в этом сценарии является добавление в LocalSettings.php строки
$wgSVGConverters['ImageMagick'] = '"' . $wgImageMagickConvertCommand . '" -background white -thumbnail $widthx$height^! $input PNG:$output';
, которая также допускает пробелы в пути.- Чтобы предотвратить ошибки создания миниатюр с помощью ImageMagick, если ≥ 7.0.9-25, то Inkscape также должен быть ≥ 1.x.x. Аналогично, если ImageMagick < 7.0.9-25, то Inkscape также должен быть < 1.x.x. См. Проблемы ImageMagick.
- Расширение PHP Imagick поддерживает рендеринг SVG, однако применяются те же соображения, что и для обычного ImageMagick.
- Библиотека GD не способна преобразовывать изображения SVG в формат PNG, по крайней мере, согласно записи Джоя Асмуссена (Joen Asmussen) в блоге NoScope от июня 2008.
- Over 98% of web browsers have at least basic support for displaying SVG files directly, but MediaWiki does not use that by default.[notes 1] Without the NativeSvgHandler extension, MediaWiki only supports client-side rendering in MediaWiki 1.41 (released December 2023) and newer, by setting
$wgSVGNativeRendering = true
.
Установите значение $wgSVGConverter = false
, если рендеринг SVG не требуется, и вы хотите, чтобы пользователи загружали файл svg для его просмотра
Разрешение проблем
Если вы видите пустой квадрат вместо SVG (Chrome) или вообще не видите изображения (Firefox) и все ссылки PNG приводят к ошибке 404, и вы не видите никаких других сообщений об ошибках, проверьте переменную $wgGenerateThumbnailOnParse
.
Установка значения false
может сделать преобразование SVG отложенным всегда.
Убедитесь, что включены методы PHP proc_open и symlink (они могут быть отключены в php.ini по соображениям безопасности или производительности).
JPEG (с использованием GD)
Просто добавьте следующую строку в LocalSettings.php, это приведет к автоматическому возврату в библиотеку GD.
$wgUseImageMagick = false;
Об ошибках, связанных с созданием миниатюр JPEG-файлов, см. JPEG (с использованием GD).
TIFF
Для создания миниатюр файлов TIFF требуется MediaWiki версии 1.15.0 или выше.
- Разрешите в LocalSettings.php возможность загрузки файлов TIFF:
$wgFileExtensions [] = 'tif';
- Добавьте
$wgTiffThumbnailType
к LocalSettings.php и установите его значение в jpg или png в зависимости от того, какой из этих форматов вы предпочитаете для создания миниатюр. - Изготовление миниатюр для файлов TIFF может потребовать дополнительных системных ресурсов помимо тех, которые необходимы для миниатюр JPEG, GIF и PNG. Соответствующие настройки для этого —
$wgMaxImageArea
и$wgMaxShellMemory
.
DjVu
Удаление изображений
Файлы, как и вики-страницы, могут удалять только участники с правами «Delete pages (delete)» (по умолчанию — administrators). Удаление файла вызывает также и удаление ассоциированной с ним вики-страницы с описанием (то же достигается, если перейти по ссылке «delete all» в таблице «File history»).
Удаление отдельных версий файлов
Если файл был изменён, то история его изменений отображается на странице его описания. Каждая версия сопровождается ссылкой «delete». Перейдя по ней, можно навсегда удалить данную версию файла вместе с записью в истории изменений.
Информация о старых версиях файлов хранится в таблице «$oldimage», в то время как информация о старых версиях страниц хранится в таблице «$revision».
Восстановление файлов
Файлы можно восстановить точно так же, как и обычные вики-страницы. Каталог, в котором хранятся удаленные файлы, определяется значением Manual:$wgDeletedDirectory . Информация об удалённых файлах хранится в таблице filearchive .
Удаление архивных версий файлов
Начиная с версии MediaWiki 1.11, удаленные изображения по-прежнему сохраняются на сервере по умолчанию. Если вы хотите удалить выбранные заархивированные изображения, вы можете сделать это с помощью сценария обслуживания eraseArchivedFile.php . Если вы хотите полностью удалить их все, вы можете сделать это с помощью сценария deleteArchivedFiles.php . Если вы удалите заархивированные файлы, вы больше не сможете восстановить эти файлы.
Причины удаления файлов
При выборе удаления файла, как описано выше, пользователям будет предложено указать причину удаления. Доступные причины могут быть отредактированы в MediaWiki:Filedelete-reason-dropdown вашей вики.
Хранение данных
Как только изображение загружается, создаётся следующее:
- Статья в пространстве имён file с именем этого файла, например, File:MyPicture.png. Эта страница хранится и может редактироваться подобно любой другой странице.
- Сам файл, хранящийся в папке файловой системы, объединенными и замененными на
_
.
- Если подключено создание миниатюр, при необходимости будут создаваться уменьшенные версии этого файла (например, для использования на странице описания файла). Они хранятся в папке thumb внутри директории images, в отдельной папке для каждого основного файла.
Если $wgHashedUploadDirectory включена (по умолчанию), MediaWiki создает несколько подпапок в папке «images».
Названия папок являются первыми двумя символами md5-хеша конечного имени файла.
Папки
Все файлы изображений хранятся в отдельной папке, расположение которой определяется посредством $wgUploadPath (по умолчанию, images/
).
Описание именованных подпапок изображений:
- archive
- Это место хранения файлов, которые заменены более новыми версиями.
- temp
- Используется для временного хранения файлов во время загрузки изображений. (Но для таких файлов может оказаться недоступным автоматическое их удаление — см. задача T11018).
- thumb
- Миниатюры (создаются автоматически) для файлов. Будучи удалены, будут при необходимости автоматически восстановлены.
В зависимости от настроек, может использоваться дополнительная подпапка:
- math
- Папку для хранения обработанных входных данных TeX, см. также Расширение:Math или [[Manual:Math |Manual:Math]].
- x/xy
- Если для
$wgHashedUploadDirectory
установлено значениеtrue
(по умолчанию), то изображения будут храниться в подпапках изображений, поэтому пути к файлам будут выглядеть какimages/a/ab/filename.jpg
. Смотрите Manual:$wgHashedUploadDirectory для более подробной информации о том, почему это может быть необходимо и как эта система работает.
Таблицы базы данных
- Страница описания файла хранится как любая страница в таблицах page, text, revision и т.д.
- image - Содержит некоторые метаданные, такие как размер файла и дату загрузки.
- oldimage - Здесь хранится информация для файлов, которые были заменены более новыми версиями.
- filearchive - Содержит информацию об удаленных файлах.
- imagelinks - Записывает, какие страницы используют файл.
Использование дискового пространства
Файлы требуют значительно больше места, чем статьи. Следующие вычисления предполагают размер блока 4 КБ для серверов Linux / Unix.
Настройка по умолчанию выглядит как $wgHashedUploadDirectory = true
.
Требуемое дисковое пространство для всех папок:
- каталоги изображений: 0-f/x0-f: максимум. 16*16 = 256 каталогов = 256*4 КБ = 1024 КБ
- архивные каталоги: 0-f/x0-f: максимум. 16*16 = 256 каталогов = 256*4 КБ = 1024 КБ
- каталоги миниатюр: 0-f/x0-f: максимум. 16*16 = 256 каталогов = 256*4 КБ = 1024 КБ
- временные каталоги: 0-f/x0-f: максимум. 16*16 = 256 каталогов = 256*4 КБ = 1024 КБ
Следовательно, базовый объем пространства, необходимый без загруженных изображений, теоретически составляет 4 МБ (хотя каталоги создаются только при необходимости).
Для каждого файла необходимо:
- размер исходного файла изображения + 2 КБ средних накладных расходов
Для файлов, которым требуются миниатюра:
- размер созданного эскиза(ов) + 2 КБ средних накладных расходов (каждому)
- каталог для миниатюр (4 КБ) (каждое изображение имеет свой каталог с миниатюрами)
Примеры:
- изображение 20778 байт png (маленький размер, без миниатюр): 24 КБ для изображения: Итого 24 КБ
- изображение в формате 123.000 байт jpeg (большой размер, автоматические создание миниатюр): 124 КБ для изображения, 4 КБ для каталога миниатюр, 64 КБ для миниатюр: Итого 192 КБ
Доступ к файлам
Загруженные файлы обычно обслуживаются непосредственно веб-сервером, а не через MediaWiki. В то время как может существовать минимальный уровень безопасности за счет неизвестности с шифрованием пути (eg. /c/c4/...) если задан $wgHashedUploadDirectory , то путь может быть легко вычислен из имени файла и не обеспечивает истинной защиту.
Для ограничения доступа для авторизованных пользователей, смотрите Manual:Image authorization .
Форма загрузки
См. документацию о настройке формы загрузки.
Лицензирование
MediaWiki allows licenses to be added to files uploaded from the Special:Upload page. The list of licenses that appear in the license selection dropdown can be edited on the MediaWiki:Licenses page by a sysop.
The page should be a bulleted list of items, and can have sub-items.
Each item can have one or more parameters, with the parameter separated by the pipe character (|
).
To make headers/categories, use only one parameter in a list item. The text will be what appears in the dropdown list, and will appear greyed-out and unclickable.
To add license options, two or more parameters are required. The first parameter will be the template name to use, without the double square brackets. The last parameter will be what appears in the dropdown list for that license. Any additional parameters between the first and last parameters will be passed as arguments to the template. When a license is selected, a preview of what it would look like on the final page is shown in the upload wizard.
Below is a simple example (not using real templates) of how MediaWiki:Licenses should be formatted:
* no-lic|No license. * Made by me: ** self-lic|And it can only be used on this wiki. ** self-lic|free=yes|And I allow it to be used anywhere. * Made by someone else: ** pd-lic|It's in the public domain. ** copyright-lic|It's copyrighted. ** cc-lic|It uses some CreativeCommons license. ** cc-lic|by-sa|It uses the CC-BY-SA license.
The above assumes each template ending in "-lic" exists, where some of those templates take positional arguments such as "by-sa" and others take named arguments such as "free=yes". Selecting the "And I allow it to be used anywhere" option, for example, would add the following text to the page of the new file:
{{self-lic|free=yes}}
Sites like Wikipedia and WikiMedia Commons will also use the subst:
tag, such as WikiMedia Common's usage of it below:
** subst:Template 2|flickrreview|subst:uwl|Image from Flickr and I do not know the license
"Template 2" is an actual template that will take two parameters (being template names) and surround them with double curly brackets so they get transcluded on the page of the new image. "uwl" is a template, whose documentation requires using it with the "subst:" tag instead of directly. The above will result in the following being added to the uploaded file's page:
{{flickrreview}}{{subst:uwl}}
On Wikipedia, substitution is used in other ways, such as adding a timestamp with the license at the time of upload.
Подробный пример из реальной жизни см. в Wikipedia:MediaWiki:Licenses или Commons:MediaWiki:Licenses.
Внешние хранилища
Можно получить доступ к файлам, хранящимся в сторонних репозиториях, без необходимости загружать их в вики, установив массив $wgForeignFileRepos . Эта функция предлагает несколько возможностей:
- ForeignAPIRepo получает доступ к файлам из удаленной установки MediaWiki, таким как Wikimedia Commons, через его API
- ForeignDBRepo получает доступ к файлам через базу данных и полезен для создания wiki families
- FSRepo получает доступ к файлам из локальной папки
Во всех случаях можно было бы внедрить файлы на страницу, используя обычный синтаксис image и указав имя файла в стороннем репозитории. Обратите внимание, что некоторые из приведенных выше реализаций все еще являются экспериментальными и могут не подходить для производственных площадок.
Notes
- ↑ Wikimedia sites also do not rely on client-side rendering, despite a request to do so, задача T5593.