Работа с MediaWiki - Глава 15 - Администрирование MediaWiki

1. Настройки конфигурации
2. отладка
3. Улучшение производительности MediaWiki
4. Кеш MediaWiki
5. Очередь заданий
6. Админ ссылки
7. Заменить текст
8. Получение информации об IP пользователя
9. Боты и MediaWiki API
10. MediaWiki API
11. Поисковая оптимизация
12. Запуск вики фермы
13. Многоязычные вики

Администрирование вики MediaWiki, как правило, не так сложно, как только вы выполнили первоначальную настройку. Он включает в себя как действия, выполняемые через веб-интерфейс, так и действия, выполняемые на серверной части, такие как редактирование LocalSettings.php и установка расширений. Обычно есть только один или несколько человек с доступом к бэкэнду, и такая же или немного большая группа людей с административным доступом в самой вики.

Вся эта книга в значительной степени ориентирована на администраторов MediaWiki, поэтому в некотором смысле большая часть этой книги может быть подпадала под тему «Администрирование MediaWiki». Но эта глава предназначена для того, чтобы содержать некоторые инструменты и действия, которые имеют отношение только к администраторам, которые не вписываются в другие разделы.

Настройки конфигурации

Существует множество настроек для основного MediaWiki, которые можно изменить в LocalSettings.php - по сути, все переменные, которые начинаются с «$ wg». Некоторые из них рассматриваются в этой книге, хотя это очень маленький процент от общего набора. Вы можете увидеть полный список здесь, сгруппированный по типу функциональности:

https://www.mediawiki.org/wiki/Manual:Configuration_settings

Вот полезный, который не упоминается в других местах книги:

• $ wgReadOnly - устанавливает всю вики только для чтения, с указанием указанной строки в качестве причины; полезно для временного обслуживания сайта

отладка

MediaWiki - это программное обеспечение, и программное обеспечение, к сожалению, может работать неправильно. Если вы столкнетесь с проблемой, проблема может заключаться в разрешениях для файловых каталогов, правах пользователей базы данных, отсутствующих файлах, отсутствующих таблицах базы данных, неправильных настройках в LocalSettings.php, несовместимых версиях или даже (не считаться с ошибками) кода. (Что, кстати, гораздо чаще встречается в расширениях, чем в ядре MediaWiki.)

Как правило, источник наибольшей путаницы в MediaWiki возникает, когда пользователи видят пустую страницу в браузере в любой момент вики. Это происходит, если есть ошибка, и если PHP настроен на отображение пустой страницы вместо сообщения об ошибке, когда это происходит. Почти всегда лучше видеть ошибку на экране; так что если вы получаете пустую страницу, лучшим решением будет добавить следующую строку, либо в LocalSettings.php, либо в собственный файл php.ini PHP: ini_set ('display_errors', 1);

Если он добавляется в LocalSettings.php, он должен находиться в верхней части файла, прямо под строкой «<? Php».

Самым простым инструментом для отладки любого рода является панель отладки MediaWiki. Он помещает всю необходимую информацию (вызовы SQL, предупреждения, отладочные сообщения) в одно легкодоступное место в нижней части браузера. Для тех из нас, кто привык делать отладку MediaWiki по старинке, это удивительно полезный инструмент. Вы можете включить его, добавив следующее в LocalSettings.php:

$ wgDebugToolbar = true;

Однако вы можете не захотеть, чтобы все видели панель инструментов отладки, пока она включена (если вы ее включите, все увидят). К счастью, есть и другие варианты. Если вы видите сообщение об ошибке, содержащее текст «(запрос SQL скрыт)», и вы хотите увидеть вызванный SQL, вы можете увидеть его, добавив следующее в LocalSettings.php:

$ wgShowSQLErrors = true; И если возникающая ошибка кажется сложной, вы можете включить собственное ведение журнала отладки MediaWiki, а затем проверить содержимое этого файла. Чтобы включить его, добавьте следующее в LocalSettings.php: $ wgDebugLogFile = "/ full / path / to / your / debug / log / file";

Этот файл должен быть доступен для записи на вашем веб-сервере.

Часто самое простое решение, как и в случае с большим количеством программного обеспечения, - это просто выполнить веб-поиск по тексту сообщения об ошибке - вполне возможно, что другие сталкивались с этой проблемой и могли ее диагностировать. Если вы считаете, что проблема связана с определенным расширением, рекомендуется проверить главную страницу этого расширения или страницу обсуждения, чтобы узнать, есть ли упоминания о нем.

Улучшение производительности MediaWiki

Это не книга по веб-производительности, но если вы чувствуете, что ваша вики слишком медленная, или вы беспокоитесь о результатах увеличения трафика в будущем, вот несколько полезных советов:

• Убедитесь, что вашему веб-серверу и PHP достаточно памяти.
• Существует множество инструментов для кэширования, которые можно использовать вместе с MediaWiki (и друг с другом), таких как Squid, Varnish и memcached. Из всех доступных инструментов наиболее полезным, вероятно, является APC - утилита кэширования PHP, которая часто значительно повышает производительность MediaWiki. Вы можете увидеть все варианты кеширования здесь:

• Использование Nginx или Lighttpd в качестве веб-сервера вместо Apache может значительно повысить производительность сайтов с высоким трафиком.
• MediaWiki также может работать с виртуальной машиной HipHop или HHVM, механизмом исполнения с открытым исходным кодом для PHP, разработанным Facebook. Википедия начала использовать HHVM в декабре 2014 года, и она примерно удвоила скорость сайта как для просмотра, так и для редактирования.

Кеш MediaWiki

MediaWiki выполняет обширное кэширование страниц: когда вы переходите на страницу вики, есть вероятность, что она не была сгенерирована на месте, а скорее является кэшированной версией, которая была создана где-то в предыдущий день или около того. (Это не относится к страницам в «специальном» пространстве имен, которые создаются каждый раз заново.)

Пользователи всегда могут увидеть «живую» версию любой страницы, добавив «action = purge» в URL.

Расширение MagicNoCache позволяет пометить некоторые страницы как никогда не кэшируемые с помощью переключателя поведения "__NOCACHE__". Посмотреть здесь:

https://www.mediawiki.org/wiki/Extension:MagicNoCache

Кэширование становится проблемой, когда установлены Cargo или Semantic MediaWiki, потому что кэшируемые страницы не показывают автоматически последний набор результатов запроса; это может вызвать путаницу у пользователей, если они добавят некоторые данные, и тогда они не появятся в результатах запроса в другом месте. Лучший обходной путь для этой проблемы - установить расширение MagicNoCache, используя его на каждой странице, содержащей запрос.

Другой вариант - использовать расширение Approved Revs ( посмотреть здесь ) - хотя это не преднамеренно, страницы с утвержденной ревизией не кэшируются. Это может измениться в будущем, но в данный момент это побочный эффект, о котором нужно знать. Cargo и SMW предоставляют свои собственные вкладки / выпадающие списки, которые видят только администраторы, называемые либо «Очистить кэш» (Cargo), либо «Обновить» (или SMW); оба указывают на URL «action = purge», не позволяя администраторам вводить его вручную.

Очередь заданий

Есть определенные задачи, которые MediaWiki должен выполнять в течение длительного периода времени в фоновом режиме. Наиболее распространенный случай происходит, когда шаблон изменяется. Допустим, кто-то добавляет тег категории в шаблон - это означает, что каждую из страниц, которые включают этот шаблон, необходимо добавить в эту категорию. Этот процесс не может быть выполнен все сразу, потому что это значительно замедлит работу сервера или даже временно приведет к его аварийному завершению. Вместо этого процесс разбивается на «задания», которые помещаются в «очередь заданий», а затем эти задания выполняются упорядоченным образом.

За кулисами очередь заданий на самом деле представляет собой просто таблицу базы данных под названием «задание», которая содержит по одной строке для каждого задания. Эти задания выполняются в последовательном порядке, и после запуска задания его строка удаляется.

Задания запускаются каждый раз, когда вики попадает на страницу. По умолчанию одно задание запускается при каждом попадании, но это число можно изменить, чтобы ускорить или ускорить выполнение заданий, изменив значение $ wgJobRunRate. Например, чтобы ускорить выполнение заданий в десять раз, вы должны добавить в LocalSettings.php следующее:

$ wgJobRunRate = 10;

И наоборот, чтобы сделать это в десять раз медленнее, вы должны установить значение 0,1. (Вы не можете на самом деле выполнить часть задания - вместо этого наличие дробного значения устанавливает вероятность того, что задание будет выполнено в любой момент времени.)

Вы также можете заставить задачи выполняться более автоматизированным способом, вместо того, чтобы просто ждать, пока они будут запущены (или повторно нажимать «reload» в браузере, чтобы ускорить выполнение). Это можно сделать, вызвав скрипт runJobs.php в каталоге MediaWiki / maintenance. Вы даже можете создать задание cron для регулярного запуска runJobs.php - скажем, раз в день.

Существуют различные параметры, которые может принимать runJobs.php, например, указание максимального количества запускаемых заданий или, что еще важнее, тип запускаемых заданий. Чтобы включить последнее, каждый тип задания имеет свое собственное имя идентификатора, которое можно найти в базе данных. Вы можете прочитать обо всех параметрах для runJobs.php здесь:

https://www.mediawiki.org/wiki/Manual:RunJobs.php

В дополнение к основному MediaWiki, расширения могут также создавать свои собственные рабочие места. Некоторые расширения, которые делают Передачу Данных, DeleteBatch, Nuke и Замените Текст.

Админ ссылки

Одной из общих функций в веб-приложениях, которой MediaWiki всегда не хватало, является область «приборной панели», которая позволяет администраторам просматривать статистику и выполнять административные задачи из одного места. В ограниченной степени страница Special: SpecialPages уже делает это; он просто перечисляет большинство доступных специальных страниц, сгруппированных по категориям. Это, конечно, лучше, чем ничего, но не все страницы, перечисленные в Special: SpecialPages особенно полезны для администраторов, и, наоборот, не все административные задачи выполняются через специальные страницы (например, редактирование боковой панели - нет).

Расширение Admin Links предоставляет что-то ближе к реальной панели администратора. Он определяет одну страницу Special: AdminLinks, которая содержит полезные для администраторов ссылки, разделенные по типу функциональности. Другие расширения могут добавлять свои собственные ссылки на страницу ссылок администратора, если они захотят, с помощью хуков и нескольких полезных действий. На рисунке 15.1 показано, как выглядит страница, когда установлены различные расширения, описанные в этой книге, такие как Cargo, Page Forms и Data Transfer.

Рисунок 15.1 Страница административных ссылок, когда установлены различные другие расширения (утвержденные версии, замена текста, формы страницы, груз и т. Д.)

Другая приятная особенность админ-ссылок заключается в том, что она предоставляет ссылку на страницу «Админ-ссылки» внутри пользовательских ссылок вверху каждой страницы, так что панель инструментов всегда находится на расстоянии одного клика. Вот как выглядит верхняя часть страницы в скине Vector с установленными ссылками администратора:

Заменить текст

В MediaWiki отсутствует встроенный способ глобального поиска и замены текста. В Википедии и некоторых других крупномасштабных вики для этой цели используются боты, но иметь способ сделать это из вики гораздо удобнее. К счастью, расширение «Заменить текст» позволяет выполнять замену текста в масштабах всего сайта. Replace Text может обрабатывать как содержимое страниц, так и их имена; если содержимое заголовка страницы заменяется, это означает, что страница «перемещается».

Чтобы запустить замену, перейдите в Special: ReplaceText. Это действие регулируется разрешением «replacetext», которое по умолчанию предоставляется администраторам.

Рисунок 15.2 Верхняя часть Special: ReplaceText

Вы можете увидеть верх страницы Special: ReplaceText на рисунке 15.2. Ниже следует список пространств имен, из которых пользователь может выбрать; затем ниже приведены некоторые дополнительные параметры для замены, которые показаны на рисунке 15.3.

Рисунок 15.3 Нижняя часть специального: ReplaceText

Нажатие на кнопку «Продолжить» переводит пользователя на вторую страницу со списком точных совпадений для строки поиска, так что пользователь может вручную выбрать, на каких страницах будет изменено их содержимое и / или заголовки.

Каждое изменение, сделанное с помощью Заменить текст, отображается в истории страниц, а пользователь, который инициировал замену, выступает в роли автора этого редактирования.

Для более сложных преобразований вам, вероятно, придется полагаться на ботов и API MediaWiki, к которым мы перейдем далее.

Получение информации об IP пользователя

В редких случаях может быть полезно получить информацию об IP-адресе пользователей, которые вошли в систему - например, если пароль пользователя украден, и кто-то еще начинает редактировать вики как он; или если вы подозреваете, что один пользователь вандализирует вики из нескольких аккаунтов; или если вы подозреваете, что один пользователь создает несколько учетных записей, чтобы создать иллюзию широкого консенсуса по какой-либо проблеме (это называется «sockpuppeting»). IP-адрес фактически сохраняется для каждого изменения, которое происходит в вики, хотя он нигде не виден в вики. Если у вас есть доступ к базе данных, вы можете просмотреть эту информацию в столбце «rc_ip» таблицы «последних изменений». Расширение CheckUser позволяет администраторам просматривать эту информацию из самой вики для более легкого доступа: https://www.mediawiki.org/wiki/Extension:CheckUser

И наоборот, если вы не хотите, чтобы эта информация сохранялась, по соображениям конфиденциальности вы можете отключить хранилище, добавив следующее в LocalSettings.php:

$ wgPutIPinRC = false;

Боты и MediaWiki API

Существуют различные инструменты для внесения автоматических изменений в содержимое вики, например расширение «Заменить текст». Но во многих случаях набор требуемых правок слишком специфичен, чтобы их можно было обрабатывать с помощью автоматического инструмента. Для всех этих случаев есть боты и MediaWiki API.

Бот в терминологии MediaWiki - это скрипт, который выполняет один или несколько конкретных видов редактирования или извлекает один или несколько фрагментов данных. Бот может быть написан на любом языке программирования: ему просто нужно подключиться к MediaWiki API, который выполняет реальную работу по записи и чтению данных. Для большинства основных языков программирования написана одна или несколько библиотек MediaWiki API, которые заботятся о деталях входа в вики и подключения к API. Но даже без библиотеки создать бота MediaWiki не так уж и сложно - скрипту нужно просто найти некоторые URL-адреса MediaWiki.

Если бот вносит какие-либо изменения в вики, в идеале он должен быть зарегистрирован как пользователь - и в идеале этот пользователь должен быть отдельной учетной записью, которая добавляется в группу «боты». Вы можете видеть такие учетные записи по всей Википедии - они исправляют поврежденные теги <ref>, переименовывают категории, добавляют подписи в неподписанные сообщения на страницах обсуждения и т. Д. В других вики они встречаются немного реже, но некоторые меньшие вики действительно используют их в значительной степени.

Эта страница содержит некоторую информацию и полезные ссылки по созданию и запуску ботов:

MediaWiki API

MediaWiki API - это, по сути, набор URL-адресов, к которым можно получить доступ для чтения и записи в вики. Все они содержат разные параметры, передаваемые в файл api.php. Этот файл находится в том же каталоге, что и index.php; так, например, если в вашей вики есть URL-адреса вида mywiki.com/w/index.php?title = ..., основной URL-адрес API можно найти по адресу mywiki.com/w/api.php. (Для более поздних версий MediaWiki API-интерфейс связан со страницей Special: Version.)

Если вы перейдете по этому основному URL, вы увидите довольно полное (автоматически сгенерированное) объяснение всех доступных действий API. Действия API определяются как ядром MediaWiki, так и рядом расширений. Вы также увидите список различных форматов, в которых могут отображаться результаты, включая JSON и XML. Например, добавление «format = jsonfm» к URL отобразит результаты в псевдо-JSON-формате, который пользователи могут читать на экране, в то время как «format = json» приведет к фактическому необработанному JSON.

Мы не будем вдаваться в подробности всех функций API, доступных здесь, но вы можете увидеть их на api.php - и вы также можете прочитать больше об этом на:

https://www.mediawiki.org/wiki/API:Main_page

Поисковая оптимизация

Поисковая оптимизация, или SEO, - это попытка добиться того, чтобы страницы своего веб-сайта отображались как можно выше в результатах поисковых систем, особенно в Google. Это спорная область: для ее сторонников это незаменимый способ получить веб-трафик, в то время как для его хулителей это в лучшем случае безвкусно, а в худшем - область хакстеров, спаммеров и мошенников. Тем не менее, для людей, которые запускают публичные вики, показ в результатах поиска может быть важным.

Во-первых, MediaWiki уже хорошо подготовлена ​​к тому, чтобы преуспевать в результатах поиска несколькими способами. Википедия, которая, конечно же, основана на MediaWiki, является сайтом № 1 с лучшими показателями для результатов поиска по любым показателям: обычно она входит в первую тройку, а часто и # 1, для поиска по любой теме, которую охватывает. Это в основном только потому, что на него часто ссылаются другие сайты на эти конкретные темы, но это также частично из-за собственного дизайна MediaWiki.

В MediaWiki предметом каждой страницы также является: имя страницы, часть ее URL, текст в заголовке верхнего уровня и текст, который отображается во внутренних ссылках на эту страницу. Такая согласованность чрезвычайно важна для поисковых систем, связывая это слово или фразу с этим конкретным URL. С этим связано, как правило, только один заголовок верхнего уровня на странице: имя страницы содержится в единственном теге <h1> на странице, что также помогает определить тему страницы для поисковых систем.

Существует по крайней мере одно активное расширение MediaWiki, которое потенциально может помочь в ранжировании в поисковых системах: расширение WikiSEO, которое добавляет теги и к исходному коду HTML вики-страницы. Он определяет функцию синтаксического анализатора с соответствующим названием «#seo», которую можно добавить в любое место на странице и которая вызывается следующим образом: {{#seo: title = ... | titlemode = ... | ключевые слова = ... | описание = ...}}

Параметр «title =» либо заменяет, добавляется или добавляется к содержимому тега HTML <title>, в зависимости от значения параметра «titlemode =», который можно либо заменить, добавить, либо добавить. Параметры "keys =" и "description =" размещаются как атрибуты "name" и "content" соответственно HTML-тега <meta>. Если вы не знаете, как лучше всего установить все эти теги, будет полезно выяснить их значение и то, как их лучше всего использовать для SEO.

Вы можете найти больше информации о WikiSEO здесь:

Если вы используете шаблоны в стиле инфобокса на большинстве страниц, хорошей стратегией является размещение тега внутри шаблонов, чтобы вам не приходилось добавлять его вручную на каждую страницу; а затем заполните его конкретными параметрами из инфобокса.

Запуск вики фермы

Организации и корпорации нередко хотят запускать более одной вики; иногда еще много. Компания, которая ведет публичные вики-сайты на разные темы, с целью получения дохода от рекламы или по любой другой причине, может в конечном итоге управлять их большим количеством. Внутренне, компании могут хотеть разместить больше чем одну вики также. Контроль доступа к данным является одной из причин, как отмечалось Вот Самый безопасный способ сохранить набор данных вики, ограниченный определенной группой пользователей, - хранить их в отдельной вики. И разные отделы внутри организации могут хотеть, чтобы их собственные вики были либо ограничены, либо просто потому, что им не нужно обмениваться данными с другими группами. В очень крупной компании или другой организации число таких независимых подразделений, которые хотели бы иметь свою собственную вики, могло исчисляться даже сотнями.

Конечно, каждая группа, которая хотела иметь свою собственную вики, могла просто создать ее самостоятельно; если они все используют MediaWiki, установка бесплатна и, как правило, не слишком сложна. (Это, фактически, то, как вики исторически внедрялись в организации: небольшие группы создавали их сами, в так называемых «проектах скунсов»). Но такая установка может быстро стать громоздкой: если другому человеку нужно стать экспертом вики для создания и поддержки каждой вики, это слишком много работы. Даже если все вики управляются централизованно одним ИТ-специалистом или отделом, это может стать утомительной работой, когда пришло время обновить программное обеспечение.

В такой ситуации вам следует использовать то, что называется «фермой вики» или иногда «вики-семейством»: группой вики, которые управляются из одного места и в которые легко добавить дополнительные вики. В MediaWiki существует множество способов создать вики-ферму. Лучший справочник для чтения о различных подходах и о том, как настроить каждый из них, находится здесь:

https://www.mediawiki.org/wiki/Manual:Wiki_family

На этой странице перечислено много подходов: один к нескольким базам кода, один к нескольким базам данных, один к нескольким экземплярам LocalSettings.php и т. Д. Однако мы действительно рекомендуем только один подход - использовать один кодовая база, несколько баз данных и несколько файлов настроек. Это по существу соответствует подходу «сайты в стиле Drupal», описанному на этой странице.

Здесь мы не будем вдаваться в технические подробности, но основная идея такова: у вас есть отдельная база данных для каждой вики, а также отдельный файл настроек. Каждый файл настроек для каждого вики-файла включается в LocalSettings.php. Отдельные файлы настроек задают имя базы данных для каждой вики и позволяют настраивать параметры вики, включая стандартные функции, такие как название вики, логотип, обложка и разрешение; в дополнение к разрешению расширений, которые включены только для некоторых вики.

Руководство «Семейство вики» включает в себя простую комбинацию сценария PHP и оболочки для этого подхода, что вместе позволяет вам создавать и обновлять базу данных для каждой вики.

Вам также необходимо определиться со структурой URL для различных вики: два стандартных подхода состоят в использовании поддоменов, таких как «wiki1.mycompany.com», или подкаталогов, таких как «mycompany.com/wiki1». Эта структура должна обрабатываться комбинацией LocalSettings.php (которая должна определить, какой файл настроек использовать, основываясь на URL) и конфигурацией сервера, которая, если используется Apache, обычно является файлом httpd. конф. Конкретные настройки для обоих описаны в руководстве "Семейство вики".

Если вы заранее знаете, что у вас будет несколько вики, может быть полезно иметь общие учетные записи пользователей для всех них, чтобы пользователям не приходилось создавать новую учетную запись в каждой вики, которую они хотят редактировать. Википедия делает это сложным образом, используя расширение «CentralAuth», но для других вики это можно сделать гораздо более простым способом, просто используя разные базы данных с одним набором таблиц для пользовательской информации. Вам просто нужно решить, какая база данных будет содержать информацию, а затем добавить следующее в LocalSettings.php: $ wgSharedDB = " main-database-name ";

Хотя «общая БД» звучит как большая проблема, по умолчанию только таблицы, связанные с пользовательской информацией, являются общими.

Многоязычные вики

Из всех вещей, которые обычно хотят делать вики-администраторы, возможно, наиболее концептуально непросто, чтобы их вики поддерживал несколько языков. Это потому, что есть компромисс: вы хотите, чтобы текст, который каждый человек читает на своем языке, был как можно более точным, но в то же время вы хотите избежать избыточности, потому что избыточность означает больше работы, чтобы убедиться, что содержимое на разных языках все совпадают.

Во-первых, хорошие новости: текст самого интерфейса - например, текст на вкладках «Редактировать» и «Просмотреть историю» или текст на специальных страницах - обычно не представляет проблемы, потому что, если пользователь устанавливает свой собственный язык в «Пользовательские настройки», есть вероятность, что весь этот текст был переведен на их язык, благодаря первоклассной настройке перевода MediaWiki.

Это просто оставляет содержимое вики. Для этого правильный подход зависит главным образом от того, предназначен ли контент для создания только для пользователей, которые говорят на одном языке, но читают на нескольких языках; или предполагается, что контент должен создаваться пользователями, говорящими на нескольких языках.

Есть три основных подхода. В порядке от самого сложного к наименее сложному, они:

Рисунок 15.4 Панель со ссылками на разные переводы страницы, предоставляемые расширением Translate

• Машинный перевод контента. При таком подходе вы сохраняете весь контент на одном языке, а затем просто получаете механизм для перевода контента через службу машинного перевода. Для этого рекомендуется использовать расширение Live Translate: оно предоставляет простой в использовании интерфейс, некоторые приятные дополнительные функции и позволяет использовать службы перевода Google и Microsoft. На сегодняшний день это самый простой подход к нескольким языкам. Вы можете прочитать об этом здесь:

Похожие

Комментарии