как узнать версию mediawiki
MediaWiki/Обновление
Содержание
Для обновления вики семейства (фермы) см отдельную статью.
Вкратце
В общих чертах для обновления движка MediaWiki нужно:
Пошаговая инструкция
Чтобы для посетителей сайта обновление прошло максимально быстро выполним некоторые подготовительные работы перед самим обновлением.
Предварительные работы, не затрагивающие работающий движок
Само обновление движка MediaWiki
Работа над ошибками
Пустая страница
Сбой в кодировке
Если после обновления со страниц исчез текст, а в списках статей остались только те, что содержат не кириллические символы, значит произошёл сбой в кодировке. В этом случае большинство таблиц нуждаются в перекодировке.
Не нуждаются в перекодировке следующие таблицы:
Команды SQL для обновления всех необходимых таблиц:
ALTER TABLE wiki_category CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_categorylinks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_change_tag CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_external_user CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_externallinks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_filearchive CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_image CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_imagelinks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_interwiki CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_ipblocks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_iwlinks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_job CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_l10n_cache CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_langlinks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_log_search CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_logging CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_module_deps CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_objectcache CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_oldimage CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_page CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_page_props CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_page_restrictions CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_pagelinks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_protected_titles CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_querycache CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_querycache_info CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_querycachetwo CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_recentchanges CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_redirect CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_revision CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_site_stats CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_tag_summary CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_templatelinks CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_text CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_transcache CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_updatelog CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_uploadstash CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_user CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_user_former_groups CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_user_groups CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_user_newtalk CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_user_properties CONVERT TO CHARACTER SET binary; ALTER TABLE wiki_valid_tag CONVERT TO CHARACTER SET binary;
ALTER TABLE wiki_watchlist CONVERT TO CHARACTER SET binary;
Все таблицы MediaWiki для версии 1.27.х:
Почему строить базу знаний компании на основе mediawiki — недурная затея
В последнее время Confluence и sharepoint стали почти безраздельно править на рынке баз знаний. Системы отличные, не спорю, но лично мне не хватает их гибкости да и в целом как-то не срослось: вики-возможности sharepoint остались где-то на уровне 2005 года (про работу с офисными документами молчу, с ними все гуд), а Confluence в силу своих особенностей с ростом числа статей неумолимо превращался в свалку, в которой невозможно найти что-либо нужное (но, может, проблема была во мне).
Не умаляя достоинства этих систем, хотелось бы рассказать о том, какие возможности есть у Mediawiki в роли корпоративной базы знаний. Само собой, mediawiki подойдет не всем — в ней нет модной интеграции с jira/tfs/etc, перенос документов с картинками из пакета Microsoft Office доставляет кучу неудобств, да и сама она написана на PHP, что в последнее время служит отпугивающим фактором для некоторых айтишников. Тем не менее, платформа живее всех живых и над ее развитием работает изрядное количество людей, коль скоро на ней базируется семейство проектов фонда Викимедиа.
Сама по себе вики довольно скупа на возможности, но для нее написано огромное множество расширений. Большая часть интересного функционала кроется именно в расширениях, так что изрядная часть статьи будет именно про них. И да, не могу не отметить, что есть специальная корпоративная версия Mediawiki — BlueSpice, которой я не пользовался, а потому не могу судить об ее адекватности.
QA включает в себя не только/не столько тестирование, сколько обеспечение качества в широком смысле. И среди прочих значений этого самого широкого смысла затесалась такая штука, как управление знаниями. По этой теме довольно много абстрактных статей и книг, повествующих о принципах Knowledge management, но на удивление мало конкретных рекомендаций и практически применимых идей, во всяком случае сколько-нибудь свежих. Это заставляет меня думать, что или все пользуются тем, что дают всем известные компании и радуются, или не пользуются ничем и страдают, или пилят свой тайный велосипед, о котором неловко рассказывать в приличной компании. Мне тоже неловко, но я расскажу.
Сперва про фишки самой mediaiwki
Прежде чем говоритиь о расширениях, стоит упомянуть о том, какие вообще особенности есть у самой mediawiki. Если на вашем счету тысяча правок на википедии, то вряд ли вы узнаете что-то новое из этой части, ее можно смело пропустить.
Первая и одна из самых ощутимых плюшек — категории. Страницы можно добавлять в категории, сами категории можно добавлять в категории. В отличие от файловой структуры (забудем про симлинки), страница/категория может находиться сразу в нескольких категориях. Использование категорий препятствует росту хаоса с ростом числа статей. Особенно если просматривать периодически списки некатегоризованных статей и некатегоризованных категорий
Пространства имен. Идеология вики гласит о том, что все является страницей (даже категория или изображение). Для того, чтобы отделять страницы разных типов, была добавлена идея пространств имен. При желании можно добавлять свои пространства имен, чтобы отделять знания разного типа (к примеру, отдельные пространства имен для информации о продукте, утилит, гайдов, описания процессов, иной служебной информации).
Также вики поддерживает шаблоны — вики-страницы, которые впоследствии можно включать в другие страницы. Шаблоны поддерживают работу с параметрами, что превращает их в нечто большее, чем простые текстовые вставки: при желании на языке шаблонов можно написать несложный скрипт. К слову, говорят, что язык шаблонов может быть полным по Тьюрингу.
В дополнение к шаблонам расширение Scribunto позволяет использовать lua-модули внутри вики. Модули вместе с шаблонами позволяют реализовать многие вещи, даже не обращаясь к написанию своих расширений.
К примеру, навигационные таблицы построены на базе этого дуэта. Навигационная таблица — это, например, вот эта штука, которую обычно можно увидеть внизу страницы: 
Они хоть и не являются стандартным функционалом, но зарекомендовали себя как удобное средство навигации и наведения порядка и используются сейчас почти повсеместно.
Не могу не упомянуть Mediawiki:Common.css и Mediawiki:Common.js файлы, позволяющие добавить небольшую кастомизацию вики — для больших вещей лучше использовать расширения.
Редакторы
Одна из самых важных частей вики — это редактор. Крайне сложно внедрить вики, если в ней нет визуального редактора, потому как учить вики-разметку согласится только очень инициативный человек.
Visual Editor
Сравнительно свежее расширение — VisualEditor решает проблему с визуальным редактированием статей. У него есть свои косяки, но для большинства задач его хватает. Из самых заметных проблем — там не самая удобная вставка изображений.
Появление визуального редактора тесно свзяано с появлением Parsoid — сервиса конвертации между Mediawiki синтаксисом и html. Задача эта оказалась крайне нетривиальной в силу того, что mediawiki синтаксис развивался хаотично и не был строго определен. Подробнее можно почитать в прекрасном посте официального блога.
Среди расширений, интегрирующихся с VisualEditor, можно выделить Graph для редактирования графов, Math для редактирования математических формул и SyntaxHighlight для подсветки синтаксиса фрагментов кода.
WikiEditor
WikiEditor — простой редактор викитекста. Некоторые хитрые вещи все еще удобнее делать через редактор викитекста, в некоторых местах все еще не поддерживается визуальное редактирование. Как бы то ни было, WikiEditor облегчает работу с викитекстом, а еще его довольно просто кастомизировать.
Конфликты редактирования
Кто пользовался в прошлом Mediawiki, тот помнит, какой болью становилось каждое разрешение конфликтов редактирования.
TwoColConflict со включенным по умолчанию бета-режимом сильно упрощает решение проблемы. В случае возникновения конфликта можно посмотреть на те места, где имеет место конфликт, и выбрать нужную версию спорного фрагмента. Если обе версии не полны, то можно дополнить одну из них. Как-то так это выглядит в деле:
Можно попробовать самому на тестовой странице.
Формы для добавления однотипного контента
Расширение PageForms позволяет добавлять на вики однотипный контент при помощи форм. В своей практике я использовал формы для добавления на вики реестровых ключей, таблиц БД и других подобных типовых вещей.
Это расширение раскрывает свою мощь при использовании Semantic Mediawiki или его аналогов. Семантическая медиавики позволяет добавлять на страницу свойства страницы или объекты со своими свойствами. Задаются свойства примерно так (на примере страницы Германия):
Эти свойства и объекты после можно получить при помощи запроса ask или через api.
Из полученных свойств можно выводить таблицы, строить графики и делать много других крутых вещей. К примеру, в моем случае на основе таблиц, добавленных через формы, строятся простейшие схемы бд. При этом схему можно строить не для всего продукта, а для конкретной категории. И в схеме можно отразить помимо очевидных FK/PK связей еще и неявные связи, которые не увидеть стандартными средствами построения диаграмм.
Дерево категорий
PageForms поддерживает возможность добавления поля с деревом категорий, так что для добавления страницы в нужные категории будет достаточно только кликнуть по нужным чекбоксам.
С другой стороны, когда у нас уже есть разложенные по категориям статьи, их можно отобразить на любой странице в виде дерева:
Дерево грузится динамически, так что оно работает и для большого числа статей, и для зацикленных категорий, если такие вдруг кому-то нужны.
LDAP/AD авторизация
Расширение Ldap Authentication поддерживает авторизацию через домен, ограничение доступа для определнных групп и маппинг групп юзеров mediawiki на группы ldap. Можно настроить сразу несколько доменов. Довольно утомительная в вопросах настройки, но, к счастью, в интернетах есть очень даже неплохие инструкции.
Гранулярные права доступа
Вот тут все плохо. Если задача стоит в том, чтобы ограничить доступ неавторизованным пользователям, то это просто. Если среди этих пользователей нужно выделить отдельные группы с особыми правами доступа, то это сложно.
Есть много разных расширений, но они не решают фундаментальную проблему: mediawiki не была создана как CMS. Для поддержки прав доступ придется патчить код Mediawiki, маниакально добавляя
во все, что не должно отдаваться без проверки прав. То же самое касается и всех расширений: для каждого добавленного расширения придется вручную добавлять все необходимые проверки.
Для себя я решил проблему самодельным расширением, построенном на идее из PermissionACL и пачки патчей для разных расширений и самой mediawiki. К счастью, мне не был нужен продвинутый ACL, хватило и примитивных проверок для нескольких групп.
Для поддержки того же самого для изображений придется завернуть обращения к файлам в Img_auth.php. А последний использует стример файлов от mediawiki, который не умеет отдавать partial content (на момент mediawiki 1.31), так что для поддержки воспроизведения видео придется приделывать другой стример файлов.
Поддержка видео
Поддержка видео не входит в стандартную поставку, но тривиально решается установкой расширения TimedMediaHandler. Обычный видеоплеер, ничего особого. Вставка видео на страницу абсолютно аналогична вставке изображения.
Поиск
Одна из раздражающих меня лично вещей в Confluence — это поиск. Стандартный поиск Mediawiki еще хуже, но к счастью есть сторонние расширения. Из поисковых расширений самые популярные — это CirrusSearch и SphinxSearch. Последним я никогда не пользовался, но с первым мне довелось познакомиться очень плотно, он же, кстати, используется и в проектах фонда викимедиа
CirrusSearch работает на базе elasticsearch, для работы расширения придется еще поставить промежуточный интерфейс — расширение Elastica.
CirrusSearch поддерживает безумное число параметров и довольно активно развивается. Например, меня очень порадовало, что в ветке 1.32 заработал поиск по CamelCase.
Еще один момент, который мне приглянулся — это возможность добавить словарь синонимов. Словарь хорошо работает с устоявшимся внутренним корпоративным жаргоном, аббревиатурами, типичными опечатками или различными транслитерациями. Но словарь нужно сперва написать, что может оказаться не самой простой задачей. Если не затачивать словарь под конкретную компанию, можно попробовать существующие словари в духе WordNet, но не факт что они подойдут лично вам.
Расширение не поддерживает добавление синонимов на уровне конфига LocalSettings, но это несложно решить правкой кода расширения — см AnalysisConfigBuilder.php и инструкцию по настройке синонимов elasticsearch.
При желании можно добавить на главную страницу поисковую строку через расширение InputBox, после чего к нему можно прикрутить автодополнение по инструкции.
Кстати, AdvancedSearch поможет привести в порядок вид страницы поиска, с ним она не будет выглядит как жертва любителя чекбоксов.
Аналитика
Звучит смешно, конечно, но аналитика крайне полезна даже для внутренней базы знаний, которую посещает в месяц сотня человек. Она позволяет понять, как пользователи взаимодействуют с интерфейсом, что ищут, что читают, чем пользуются. Если в планах есть дальнейшее развитие базы знаний, статистика будет просто бесценной.
Для интранета есть крайне достойное расширение Matomo (ex Piwik). Соответствующее расширение для интеграции — MatomoAnalytics.
Matomo собирает статистику по поисковым запросам, источникам трафика, загрузкам, переходам по ссылкам (можно посмотреть частоту перехода по ссылкам с наложением на саму страницу) и множество других метрик. Статистику можно собирать как с привязкой к конкретным пользователям, так и анонимную, чтобы не смущать никого.
Прочее
Помимо перечисленного есть немало расширений, которые просто облегчают жизнь. Например, GuidedTour для обучения новичков основам работы с интерфейсами, Popups для предпросмотра статей по наведении на ссылку, MultimediaViewer для более кофмортного просмотра полноразмерных изображений и многое-многое другое.
Что в итоге?
Перечисленный джентельменский набор расширений покрывает значительную часть потребностей при создании базы знаний, но не все. Mediawiki не годится в качестве универсальной единой базы знаний. Но в качестве универсальной системы также плохо справляются и все остальные — sharepoint, confluence, олдскульные папочки outlook, поиск по которым занимает полчаса и т.д. Mediawiki же на их фоне отличается своими возможностями кастомизации и отличной масштабируемостью.
В противовес всем перечисленным плюсам mediawiki постоянно требует допиливания напильником функционала под нужды конкретной компании, так что ее администратору стоит быть морально готовым разбираться в php, js и lua коде. Но если это не пугает и если вы согласны разделять работу с офисными документами и работу с вики статьями по разным платформам, mediawiki в качестве базы знаний может оказаться весьма недурной затеей.
Manual:Обновление
Contents
Обзор
Перенос файлов
Выберите метод переноса файлов:
Подготовка
Проверка требований
MediaWiki версии 1.36 требует:
Since Version 1.36, MediaWiki only commits to supporting upgrades from two LTS releases ago (see phab:T259771). Upgrades from older versions of MediaWiki will have to be performed in multiple steps. This means that if you want to upgrade to 1.36 from 1.23 or earlier, you’ll first have to upgrade your 1.23 wiki to 1.27 (or 1.35), and, from 1.27 (or 1.35), you’ll be able to upgrade to 1.36.
Прочтите примечания к релизу
Где-то внутри дистрибутивного архива (tarball), или среди файлов, полученных или экспортированных из Git, есть ряд файлов с именами, набранными прописными литерами. Один из них содержит — RELEASE-NOTES (wiki). Теперь — самое время, чтобы открыть этот файл и узнать то, что изменилось в этом релизе. You should also read the instructions in the UPGRADE file.
Очистка списка задач
В интересах производительности некоторые действия с базой данных откладываются и управляются очередью задач (смотрите job queue) Эти задачи сохраняются в базе данных и содержат параметры с информацией о необходимых действиях. Крайне рекомендуется выполнить отложенные задачи перед обновлением вики во избежание их потери, что может произойти если обновление затронет параметры, указанные в этих задачах. Используйте runJobs.php чтобы выполнить все отложенные задачи и очистить очередь перед выполнением обновления.
Сделайте резервную копию существующих файлов и базы данных
Несмотря на то, что скрипты обновления тщательно отлажены и проверены, всегда остаётся вероятность сбоя. Поэтому перед обновлением базы данных, сделайте полную резервную копию своего вики-проекта, включая резервную копию базы данных, а также файлы:
Распакуйте новые файлы
Использование пакета tarball
Вы можете загрузить новые файлы при помощи FTP или командной строки. Использование командной строки возможно только при наличии соответствующих прав доступа! Этот способ гораздо эффективнее, чем FTP, когда каждый из сотен файлов загружается отдельно.
FTP или графический интерфейс
Если у вас нет доступа к командной строке вашего сервера, загрузите на локальный компьютер архив (tarball) с MediaWiki, и распакуйте его на локальном компьютере с помощью 7zip.
После того, как файлы будут извлечены локально, воспользуйтесь FTP-клиентом для загрузки каталогов и файлов на сервер.
cPanel File Manager
cPanel is a popular interface provided by many web hosts. This method is efficient because the files are uncompressed on the server itself.
Командная строка
You may need to run the command as sudo if you don’t have full write permissions to the wiki install directories under your current user. When untarring a tarball package normally a new directory for the new wiki version will be created and you will have to copy the old configuration files and images directory from your old installation directory:
Другие файлы
After extracting the tarball, you should copy or move some files and folders from the old installation directory to the new one:
Once done, make this new folder the published folder on the web server, or rename the old installation directory and then rename the new one to match the old name.
Использование Git
При использовании @git, закачайте файлы в новую папку, а затем скопируйте старые файлы настройки в эту папку, как описано в предыдущем разделе.
You will also need to install some external PHP libraries using Composer or a provided collection maintained for the Wikimedia wiki farm. More details on installing and updating external libraries can be found in the Git download documentation.
Использование патчей
Небольшой файл исправлений обычно становится доступным для незначительного обновления версии. Вручную загрузите с [$dumps сайта с дампами] и извлеките файл патча, или следуйте инструкциям ниже, чтобы загрузить патч с помощью команды wget. Патчи являются инкрементными, вы не можете пропускать версии. You’ll need to download patch to use this. Manually download and extract the patch file from the dumps site or follow the directions with wget below. Patches are incremental, you can not skip a version.
Файлы, оставление которых может привести к ошибкам
Если вы распаковали дистрибутив поверх старого каталога установки, некоторые старые файлы могут вызвать проблемы с новой версией.
Обновите расширения
Некоторые расширения были обновлены, чтобы работать с новой версией MediaWiki. Убедитесь, что обновили такие расширения до их последних версий. Вполне возможно, что вам потребуется вручную выполнить обновления некоторых расширений.
Различные архивы включают в себя некоторые наборы расширений и имеют функционал управления версиями, который помогает при обновлении выбрать правильный вариант для вашего выпуска ядра MediaWiki.
Extension Distributor works well for most people who want a snapshot of extensions that will work with their supported versions of MediaWiki.
If you want a lot of extensions then downloading from Git is probably best. If you don’t have Git but you want to upgrade a lot of extensions, you might consider using mwExtUpgrader.
Откорректируйте ваш LocalSettings.php
Если вы используете тот же LocalSettings.php от старой версии, вы должны его адаптировать так, чтобы новая версия его обрабатывала правильно:
Регистрация тем оформления
Если хотите иметь в наличии одну их этих тем оформления при обновлении с версий старше 1.24, в LocalSettings.php нужно добавить следующее:
Некоторые другие темы оформления все еще могут быть не адаптированы к новой системе регистрации тем оформления, поэтому в случае возникновения проблем обратитесь к странице документации каждой темы оформления, чтобы узнать, как правильно её зарегистрировать.
Регистрация расширений
В MediaWiki 1.25 используется новая система регистрации расширений.
Сейчас нужно преобразовать в:
Расширения должны быть адаптированы для использования с новой системой регистрации расширений. Расширения, которые не адаптированы, должны использовать старый способ установки. Для получения дополнительной информации обратитесь к инструкциям по установке на странице расширения.
Другие переменные
Запустите скрипт обновления
You can upgrade the MediaWiki database in two ways: Either from the command line or from the web browser. If you have shell access to your server, upgrading from the command line is recommended, since this reduces the risk of the upgrade process being interrupted by a timeout or connection reset.
The script will also attempt to download any missing dependencies which MediaWiki needs.
Командная строка (shell)
Доступ к командной строке на вашем сервере будет организован через SSH shell или похожим образом. Вы можете работать в командной строке, подключившись к серверу через SSH. На локальном компьютере под управлением Microsoft Windows, для использования SSH вам потребуется программа типа PuTTY. Из командной строки, с использованием SSH, или иным аналогичным образом, перейдите в каталог maintenance и выполните сценарий обновления:
Если вы столкнулись с ошибкой на сервере под управлением Linux, попробуйте повторить ту же самую команду как root ( sudo php update.php ). Примечание для простой установки в Windows (например, с XAMPP ): Сначала убедитесь, что ваше серверное приложение (например, Apache) и база данных (например, MySQL) запущены. Then run update.php : right-click it, select Open With, and browse to PHP.exe. The resulting command prompt window will likely autoclose when the schema upgrade completes.
MediaWiki проверит существующую схему и обновит её для работы с новым кодом, добавив при необходимости таблицы или новые поля.
What to do if php update.php fails to do anything, resulting in a quick pause and then return to command prompt
This can be caused by a malfunctioning extension or skin.
Что делать, если возникает ошибка «ALTER command denied to user» (или похожая)
Может случиться так, что выполнение скрипта прерывается с сообщением, похожим на:
Что делать, если возникает ошибка «unexpected T_STRING»
Individuals running update.php from the command line may encounter the following error:
Эта ошибка возникает, когда update.php запускается из php4.
Individuals who have their site hosted by providers who provide both php4 and php5 should take the following steps:
Ниже приведён пример:
Что делать, если возникает ошибка ‘register_argc_argv is set to false’
Вам может встретиться ошибка:
/maintenance. Either edit an existing ‘php.ini’ file, or create one.
Веб-браузер
If your database is already big and in high production usage, then you should not be using the Web updater, e.g. because the update process will time out when the maximum_execution_time is reached. In that case you should use update.php from the command-line interface (not from the web). What exactly is «too big» depends on your server (e.g. on its performance, the load and on how long the maximum execution time of PHP allows the script to run). If your wiki is too big for the web updater and your hosting provider does not allow command-line access, then you need to migrate your wiki to another hosting account, preferably to one that does have shell access.
It might happen that the web-updater does not seem to work: Instead of seeing the initial language selection screen, you might see an empty wiki page, possibly with some error message. In this case it is most likely that your webserver uses Rewrite Rules (most likely for short URLs), which do not show you the updater at mw-config/, but a wiki page at Mw-config/, with capital «M». In this case, rename the .htaccess file for the time of the update. Then you should be able to access the web-updater.
Протестируйте обновление
Как только обновление завершится, просмотрите вики-сайт и проверьте основные моменты, — чтобы гарантировать, что всё по-прежнему работает так, как ожидается. В первую очередь, это:
Remove leftovers from old installations
If you have copied your previous installation to another folder on the server, be sure to remove it or make it completely inaccessible from the web. It is very important to not leave old installations accessible from the web, since it completely defeats the purpose of upgrading, and leaves your server open to attacks.
Часто задаваемые вопросы
How hard is it to upgrade?
Minor upgrades, within the same major version, say from 1.35.0 to 1.35.3, do not require any schema changes at all. You can just update the files. The database needs no update, hence it is not necessary to run the updater script.
Upgrading from 1.4 or earlier is potentially complicated because support for character sets other than UTF-8 was dropped, and the schema for storing bulk text changed. Please read the relevant section in the UPGRADE file.
Upgrading becomes difficult if you have modified our source code, and you don’t want your changes to be overwritten. Tools such as diff, patch, Meld or WinMerge may be useful. There is also potential for trouble if you are using unmaintained extensions. Upgrade your extensions at the same time as you upgrade MediaWiki.
If you have modified the skin or use a custom skin you very likely will have to adjust it to work again with the new version of MediaWiki.
How do I upgrade from a really old version? In one step, or in several steps?
If you are upgrading from MediaWiki 1.5 or newer to 1.35, you can upgrade in one step, from your old version to the latest stable version. The vast majority of reports, as well as automated testing, indicate that doing it in one step works just fine. If you have trouble believing this, read this mailing list post. However, please note that when you update from old versions, chances that you will encounter PHP errors are bigger than when you upgrade from the version directly previous to the new version. You would have received these errors anyway, had you not skipped versions, but the errors would have been associated with each individual update. Instead, if you update several versions at once, you’ll get the same set of errors all at the same time. This will make the upgrade more difficult, but do not forget that you did not have the trouble of updating to the intermediate versions, which you skipped!
If you are upgrading to MediaWiki 1.36 or later, only upgrades from the last two LTS releases will be supported (phab:T259771). This will mean that for very old versions, that you first upgrade to MediaWiki 1.35 and then upgrade to 1.36.
Сперва я должен сделать резервное копирование?
Long answer: It depends on a) how much you value your data, b) how hard it is to create a backup and c) how confident you are with MySQL maintenance and administration.
Recovery is often complex. Volunteers on the support forums are unlikely to be impressed if you neglect to make a backup and then need help to recover from upgrade-related corruption. A better outcome is if you can revert to your backup, and then report the bug against the corresponding MediaWiki project in the upgrade process which caused the corruption.
Can I keep my LocalSettings.php?
Yes, but you may have to make some minor changes. The format of LocalSettings.php is largely backward compatible. Changes which break LocalSettings.php compatibility will be documented in the «configuration changes» section of the release notes.
Can my wiki stay online while it is upgrading?
Generally yes, however Git may temporarily (for a few seconds) break it.
If you are upgrading between minor releases of MediaWiki, all you need to do is update the source files.
Note: the following assumes you have command line access. If you are upgrading between major releases of MediaWiki, the preferred procedure is as follows:
$wgReadOnly = ‘Upgrading to MediaWiki 1.36.1’;
Why upgrade?
Recent releases receive security fixes to keep your wiki and your host safe from vandals, while old releases don’t (see Жизненный цикл версий ). That makes dozens good reasons to upgrade!
New major releases come with new features, which you might want to use: see the release notes for details. In case you need additional arguments to convince your bosses to let you upgrade from a pretty old version, here is a summary:
InstantCommons no longer requires local files.
Allow to block range of IPs.
Added ability to search for contributions within an IP ranges at Special:Contributions.
The Тема оформления:Timeless was introduced. Add default edit rate limit of 90 edits/minute for all users.
The «watch» feature can be enhanced with expiry dates.
Also, in MediaWiki 1.18 we started bundling some vital extensions, like a better editor and anti-vandalism tools ConfirmEdit and Nuke; more have been added in later releases.