В MediaWiki, начиная с версии 1.17, появился новый механизм сборки и загрузки стилей и скриптов — ResourceLoader. В этой статье я опишу его использование на примере расширения GoogleCodePrettify, которое добавляет тэг syntaxhighlight в разметку MediaWiki.

Всем авторам расширений настоятельно рекомендуется использовать новый механизм взамен устаревших addScript etc.

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



Я хочу поговорить о том, как вставлять диаграммы на страницы вики (под словом вики в этой статье подразумевается исключительно MediaWiki). Стандартный подход — хранить диаграммы в файлах внутри самой вики — имеет свои недостатки; о них — под катом. Я попробовал использовать Graphviz — инструмент, который сам рисует графы по заданным данным. Вот исходник картинки, с которой началась эта статья:

digraph A {
Feedback -> New_Assigned [dir="both"];
New_Assigned [label="New / Assigned"];
New_Assigned -> Rejected [dir="both"];
Reopen -> Rejected;
Reopen -> New_Assigned;
New_Assigned -> Resolved -> Testing -> Approved -> Closed;
Testing -> Closed;

{ rank=same; Feedback; Reopen; }
{ rank=same; Resolved; Testing; Approved; }
}


Сегодня утром, завершив в вики «Традиция» работу над статьёю «Ацтекизация», я с удовлетворением обнаружил, что эта статья стала двадцатисемитысячною по счёту.

Взятие этого рубежа, достижение этого охвата радует меня немало. В России лишь четыре энциклопедические вики превосходят Традицию по числу статей: это две специализированные энциклопедии про кино («Энциклопедия кино RuData», насчитывающая 340 769 статей, и «Всё о кино», насчитывающая 47 406 статей), а также два научно-образовательных проекта («Виртуальная лаборатория», содержащая 204 082 статьи, и проект «Летописи», где 43 091 статья).

Кажется, это повод рассказать о Традиции на Хабрахабре.

22 июня 2011 года Фондом Викимедиа выпущена в свет очередная стабильная версия движка MediaWiki — версия 1.17. Соответствующую новость на английском языке вы без труда найдёте в рассылке mediawiki-announce, снабжённую гиперссылками на подробный список изменений и инструкции по апгрейду.

Одной из основных (и даже ключевых) новостей этой версии стало появление и внедрение уникального движка ResourceLoader, целью которого является автоматическая сборка «ресурсов» (конгломератов джаваскрипта и CSS, из которых собирается один общий файл CSS и один общий файл джаваскриптов) с учётом их взаимной зависимости (например, jQuery UI зависит от jQuery) и с последующей минификацией. Два ресурса, содержащие служебные скрипты MediaWiki и библиотеку jQuery 1.4.2, подключаются автоматически в любом случае.

Те из вас, кто хочет использовать более новую версию jQuery, по-прежнему могут для этого воспользоваться тем моим способом и расширением, о котором я рассказывал 12 дней назад вот в этом же блоге. Как ни странно, мне не пришлось переменить ни буквы в его коде PHP для обеспечения работоспособности в MediaWiki 1.17 — это приятная удача, несмотря на то, что (в силу сложности ResourceLoader) прежняя возможность несложно «выкусить» вызов библиотеки jQuery, встроенной в MediaWiki, исчезла совершенно. Так что теперь моё расширение «побеждает» всего лишь потому, что вставляет вызов новой jQuery чуть раньше, чем ResourceLoader начинает грузить старую. По-видимому, библиотека jQuery 1.4.2 достаточно разумна для того, чтобы не подменять новую версию себя самóй. Однако печально, что теперь (в отличие от 1.16) моё расширение не позволяет загрузить одну версию jQuery (свою) вместо другой (встроенной в движок): в 1.17 они грузятся совместно, что неэкономно.

Как нетрудно прочесть на сайте MediaWiki, нынешняя линейка стабильных версий (1.16.x) поставляется со встроенною библиотекою jQuery, код которой лежит по адресу «skins/common/jquery.min.js». Это jQuery сравнительно старой версии (1.3.2, вышедшая в феврале 2009 года), слегка запатченная для преодоления одного из её багов, и она запускается в режиме совместимости («noConflict()») таким образом, чтобы поместиться в переменную $j вместо $. Этот код jQuery не содержит никаких плагинов и является, в сущности, необязательным, подключаясь к странице только в том случае, когда код MediaWiki содержит вызов метода $wgOut->includeJQuery(). Скажем, расширение UsabilityInitiative содержит именно такой вызов на строке 128 своего файла «UsabilityInitiative.hooks.php», так что jQuery появляется в некоторых темах оформления (например, в Vector), когда расширение UsabilityInitiative подключено к вики.

Предлагаю встать на точку зрения вики-техника, то есть администратора сервера MediaWiki, имеющего прямой доступ (наподобие SSH) и возможность менять настройки вики (LocalSettings.php), доустанавливать расширения MediaWiki и проводить другие подобные действия. Какие обстоятельства могут вызвать у вики-техника MediaWiki 1.16.x стремление переменить к лучшему то положение дел, которое упомянуто в предыдущем абзаце? Каким путём уместнее всего действовать вики-технику на пути воплощения этого своего стремления?

Первотолчком такого стремления является естественное и почти неизбежное осознание того, как неудобна та необязательность появления jQuery в коде страниц, которая настроена по умолчанию. Всякий вики-техник, если он имеет достаточно досуга для размышлений, рано или поздно постигает, что простота и могущество функции $(…), если бы она была всегда в распоряжении администраторов, сочиняющих скрипты для вики, всенепременно породили бы JS-код куда компактнее, чем прежний. Возьмём для примера версию от 22 мая 2011 года страницы «MediaWiki:Common.js» из россияноязычной Википедии. В ней нетрудно заметить вот какой код функции:

Что же я хотел сказать таким страшным заголовком?

На самом деле — все просто.

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

В этой статье я расскажу о том, как реализовать это на примере движка mediawiki.

В популярном wiki-движке MediaWiki, на котором работает Wikipedia и немалая часть wiki-сайтов в интернете, найдено несколько уязвимостей.
Первая уязвимость найдена в коде проверки CSS: c ее помощью пользователь, имеющий права редактора, может вставлять изображение с внешних ресурсов на страницах wiki-сайта. Это, в свою очередь, может привести к сбору потенциально важных данных – IP посетителей, просматриваемые ими страницы и так далее.
Вторая брешь найдена в скрипте thumb.php. При определенных условиях посетитель может обойти ограничия доступа к личным файлам (изображеням), организованным при помощи img_auth.php.
Для устранения уязвимостей необходимо обновиться до версии 1.15.2.

Эта статья — развернутый комментарий к топику «Написанная за полгода карачаево-балкарская Википедия стартует с 900 статей».
Если кратко, то звучал бы он так: «Работа проделана огромная, но если человеку интересно, то это — не проблема. А вот потом только удивляешься, как это все было сделано».
Далее расширенно — о своем опыте на примере wiki-решебника +Pi. Кому интересно, прошу под кат. Осторожно, пиар :)

Всю прошлую неделю представители Нижегородской Группы Пользователей Linux по приглашение администрации Нижегородского РадиоТехнического Колледжа проводили занятия на курсах повышения квалификации для преподавателей информатики техникумов Нижегородской области.

За три дня мы успели рассказать и провести практику по: