Блог:TechTools

From Wiki4Intranet
Jump to: navigation, search

Блог команды поддержки проекта «4intra.net». Пока это Стас Фомин и Виталий Филиппов.

[ List view ]Comments

А планируете ли выкладывать отдельно всю вашу сборку в виде архива?

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

Ясно. По частям конечно нужно раздавать, если хотите опенсорс. Но и сборка тоже была бы не лишняя - не все смогут все это дело собрать воедино.

Спасибо за ваш труд и за желание им поделиться.

Конечно выложим! Таких мелких частей, которые выложим отдельно, там немного, только некоторые расширения, которые насоздавали.

А как попасть в Блог:TechTools с главной страницы или из спецстраниц, если не знаешь о существовании Блога? На служебной странице AllPages ссылки на записи Блога тоже нет...

На AllPages есть, но в пространстве имён "Блог", а не в основном.

Добавим ссылку куда-нибудь (на главную хотя бы), да и всё, дел-то.

Википрезентации: А код этого расширения опубликован тут: http://sourceforge.net/p/mwslideology/

Установил это расширение. Добавил require_once "$IP/extensions/S5SlideShow/S5SlideShow.php"; в файл LocalSettings.php. Слайды есть, но нету панельки управления внизу при просмотре сдайда в отдельном окне, и нету флажка "Автопредпросмотр" под полем редактирования страницы.

Может есть более обновлённая версия S5SlideShow? Или надо ещё что-то установить кроме PHP?

«и нету флажка "Автопредпросмотр" под полем редактирования страницы. »

это отдельное расширение. Через неделю выложим.

«Слайды есть, но нету панельки управления внизу при просмотре сдайда в отдельном окне»

А это что-то странное. Ничего дополнительно ставить не надо. Во всех броузерах одно и тоже?

«это отдельное расширение. Через неделю выложим.»

Здорово!

«А это что-то странное. Ничего дополнительно ставить не надо. Во всех броузерах одно и тоже?»

Оказывается есть панелька, надо было мышь загнать в правый нижний угол :) и в хроме и в IE

Не могу найти это чудо , Mediawiki4Intranet , всё обрыл

Мы целиком не выложили ещё =)

То, что вы её ищете, хороший повод выложить прямо сейчас =)

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

Склонировать, склонировал, а вот дальше знаний не хватило, на работе завал, я так понял для гугло кода нужен софт что бы стянуть.. с репозитария. раньше занимался таким.. Конечном результате как сборка будет выглядеть ? Готовый для установки двиг или выборочно патчи и плаги ?

Ветка mw4install - готовая к установке, ничего дополнительно ставить или накатывать не нужно.

Я не понял, а что ты склонировал, если ты говоришь, что "так понял для гугло кода нужен софт чтобы стянуть" ?

Склонировать = стянуть. Потом сказать hg up mw4install.

Пробовал запустить на Win7 эту сборку, но не запускается Apache. MySQL запускается, а Apache нет. Может ли эта сборка конфликтовать с другими программами? Вообще при запуске apache_start.bat выдаётся следующее сообщение:

(OS 10048)╬с√ўэю ЁрчЁх°рхЄё  Єюы№ъю юфэю шёяюы№чютрэшх рфЁхёр ёюъхЄр (яЁюЄюъюы/ё
хЄхтющ рфЁхё/яюЁЄ).  : make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Apache konnte nicht gestartet werden
Apache could not be started

Дистанционный диагноз от House M.D. → виноват Скайп. Конкретно оно вам пишет, что классический вебсерверный 80-й TCP-порт уже кем-то занят. Что-то мне подсказывает, что у вас нет других вебсерверов, а подлый Скайп любит по умолчанию садится на 80 и 443 порт (на всякий случай). Попробуйте без Скайпа, если поможет — ищите в Скайпе настройку «использовать 80 и 443 порт» и отключите ее.

Если не Скайп — продолжим дифференциальный диагноз, будем искать другие вебсервера. Возможны паразиты-трояны...

Да, с выключенным скайпом запустилось. А можно поменять порт Apache с 80 на другой?

И ещё вопрос, почему страница "Служебная:Version" пустая?

В

\apache\conf\httpd.conf

сменить «Listen 80» на что вам нравится. Только зачем? Проще скайп отучить от этой глупой привычки.

Почему «Служебная:Version» пустая — фиг знает, посмотрю.

Служебная:Version пустая, потому что здесь основной язык вики (wgContLang) - английский. В этой вики правильно Special:Version.

Николай, это сборка для Windows, для WAMP, громоздить ее на Linux наверно неправильно, хотя возможно даже что-то и взлетит... Вы ищите наиболее простой способ установить все это под Linux? Или я что-то не понял?

Я ставлю под линукс Mediawiki4Intranet из архива исходников, ссылка на который размещёна на странице Mediawiki4Intranet. Т.е. речь идёт не про виндовс сборку. Просто Gentoo устанавливает пакетов по минимуму и возможно, что для правильной работы Mediawiki4Intranet нужны дополнительные пакеты (которые не описаны на основной странице), которые не нужны для стандартного движка Mediawiki. А возможно нужны какие-то настройки php или ещё что...

  1. У вас, видимо, PHP 5.3 и short_open_tag=Off. Сделайте его On. Там у нас используется <?= ... ?>, в 5.4 это уже и с short_open_tag=Off будет работать, но в 5.3 ещё не. <? ... ?>, которое стопроцентно осуждаемо, не используется.
  2. А это очередной недовыловленный E_STRICT баг. Исправил, обновил сборку. Если этого не хочется видеть вообще — уберите E_STRICT из error_reporting.
  1. Да у меня php 5.3.8 установлен. Установил short_open_tag=on - стало лучше. Первая проблема решилась.
  2. Вторая проблема частично решилась, на главной странице уже сообщения нет. Но на другой страничке выскакивает такое сообщение:

Notice: Undefined index: font in /var/www/localhost/htdocs/wiki4intranet/extensions/S5SlideShow/S5SlideShow.class.php on line 476

Как я понял, эти сообщения появляются и при нормальной работе и настройках, и их можно выключить убрав E_STRICT из error_reporting, только error_reporting это что такое - функция, файл или что? нашел ответ на странице Mediawiki4Intranet Nikolay 11:29, 16 November 2011 (MSK)

Это уже касается нового архива. Хорошо бы дату сборки в название, а то не понятно, когда обновлялась...

Ещё тут я оставлял ранее вопросик...

2. Ага, разные варнинги могут пока под стриктом вылезать. Я их когда вижу, сразу поправляю, но ещё выловил не все.

По поводу вопросика "тут" :-)

counter.php - это медиавиковский скрипт, лежит в директории maintenance/. Если у вас его там нет, значит, MediaWiki 1.17. Конкретно включение counter.php можно вообще выкинуть и выкинуть также блок который рядом "Abort with control-c in the next five seconds..." внизу скрипта. Так он должен отработать.

Вообще, выложенный патч уже несколько устаревший, сейчас я его привожу в соответствие с разумными замечаниями Тима Старлинга :) в частности, вместо странного изобретения - multipart архивов - уже работает ZIP, но сам патч пока что не выложен. И ещё одно замечание как раз касалось схемы именования файлов - типа придумать какую-то схему, чтобы она была обратно совместима, чтобы имя файла включало в себя индикатор схемы именования.

Так что выложу новую версию, с ней и renamer обновлю.

Замечания[edit]

После того как подключил wiki4intranet к старой базе вылезло много мелких отличий в синтаксисе. Например:

  • вывод в виде моноширинного текста. В моей старой вики (1.16.0), если строка начиналась с пробела, то она печаталась в рамке в виде моноширинного текста. В wiki4intranet нужно, чтобы перед такой строкой была пустая строка:
Эта строка начинается с пробела (но отображается как обычный абзац!(
А это следующая строка, начинающаяся с пробела...

При этом есть исключение:

Эта строка начинается с пробела и уже отображается моноширинной
И эта строка начинается с пробела...
  • такая же проблема в таблицах, в старой вики можно было записать так
{| border=1 style="border-collapse:collapse" cellspacing="0" cellpadding="3"
| one
|-
| 
 two 
|}

и получалась таблица, в которой "two" печаталось абзацем в рамке с моноширинным текстом, а в wiki4intranet получаем так

one
two 
  • По-другому отображаются заголовки первого (==) и второго (===) уровней. Вообще заголовок второго уровня (===) выглядит жирнее, на мой взгляд, лучше было бы наоборот. Как бы это поправить у себя?

Первый уровень[edit]

Второй уровень более жирный[edit]

  • ещё наблюдается иногда проблема с копированием текста в окно редактирования страницы - иногда (пока не удалось идентифицировать в каких именно случаях) русский текст из блокнота вставляется с испорченной кодировкой (в виде "кракозябликов").
  • так же отвалились некоторые шаблоны часть в связи с вышеописанной проблемой, а часть из-за других вещей, возможно требуется дополнительная правка настроек Common.js, Common.css (с этим я ещё по разбираюсь..)

Это скорее не первый и второй, а второй и третий уровни. Ну да, у нас третий сделан жирным шрифтом. Он меньше, но жирный, чтобы выделялся. Это произрастает из extensions/CustisScripts/custis.css. Можно там и изменить.

Проблему с кодировкой не наблюдал. А это у вас Windows-сборка или Linux, какая ОС и какой браузер? И, кстати, попробуйте отключить WikEd (такой мелкий карандашик кликнуть в правом верхнем углу страницы, около логина). Если уйдёт — значит какие-то проблемы WikEd’а.

С пробелом… Да, есть такой момент. Это наш патч к парсеру, на doBlockLevels так работает)) зачем сделали патч — чтобы поправить следующие несколько багов:

  • В оригинале MediaWiki вообще никак не генерирует абзацы, если в них встречается блочный элемент (например <div>). В том числе, например, если этот div генерится как часть кода картинки, плавающей справа. То есть на оригинале вот такой код: Текст [[Image.png|right]]\n\nТекст 2[[Image.png|right]] (\n - перевод строки) сольётся в один абзац. Как бы понятно, почему — потому что внутрь <p> пихать блочные элементы в HTML нельзя. Но тем не менее, неприкольно.
  • В оригинале внутри <blockquote> и некоторых других блочных элементов абзацы тоже не генерируются.
  • В оригинале некорректно обрабатывается иерархия открывающих/закрывающих элементов на одной строке.

И как бы понятно, что без изменений парсинга тут не обойдёшься. В итоге есть ещё два отличия:

  • Если абзац содержит блочные элементы, он всё равно становится абзацем, но реализуется через <div class="paragraph">.
  • Куски <html> тоже заворачиваются в такой же «абзац дивом». Что может приводить к глюкам, если эти блоки содержат незакрытые/неоткрытые дивы, например. Проблема в том, что doBlockLevels не видит содержимое html-блоков и ничего не может с ними сделать. Лечатся глюки довольно просто — все дивы нужно вынуть из html’я.

С пробелом в начале строки — там не после абзаца, а после элемента списка глючит только. Посмотрю, может можно поправить. Но что характерно, все тесты парсера оно проходит :) видимо на это там тестов нет :)

Спасибо за развернутый ответ, но к сожалению я мало что понял касательно тонкостей парсинга...

По поводу уровней, заметил что в разных браузерах отображаются по разному (в моей старой опере ещё терпимо), а вот Firefox показывает так:

Chapter2-3.png

Тут не совсем заметно, что шрифт более мелкий на третьем уровне...

По поводу проблем с кодировкой соберу больше фактов... Вообще вопросы касались линукс сборки, но оперу юзали из виндовса.

Да, действительно не очень заметно. :) ещё зависит от установленного шрифта по умолчанию. Там действительно небольшая разница, 150% и 140%. Может и надо что-то с этим сделать, не знаю. Подумаем.

А как получить в Mediawiki4Intranet такой вот результат.

Simple table.png

Как исправить исходный текст, чтобы получить тот же результат как в mediawiki?

Если вам нужно именно "слабое преформатирование", то есть <pre>, в котором можно использовать разметку - то в данный момент внутри таблицы никак. Если просто фрагмент кода - написать <pre>код</pre.

Если так сильно нужно - можно патч откатить нафиг.

Есть у меня такой Шаблон:Hider

<includeonly>{{#ifeq:{{{1}}}|end|</div></div>|
 <div class="NavFrame {{#ifeq:{{{show}}}|no||collapsed}}" style="background-color:#F9F9F9;" 
 {{#if:{{{2|}}}|style="width:{{{2}}}"}}><div class="NavHead"  style="text-align:left; background-color:{{{color|#F1F1F1}}}">
 {{{1}}}</div><div class="NavContent" style="text-align:left;">
 {{Anchor|{{{1}}}}}}}</includeonly><noinclude>
 </noinclude>

Он делает свёрнутый список. К нему в нагрузку нужно дописывать текст в common.js.

Этот шаблон вставляет такой html-текст

<div class="NavFrame collapsed" style="background-color:#F9F9F9;">
 <div class="NavHead" style="text-align:left; background-color:#F1F1F1">
 Name
 </div>
 <div class="NavContent" style="text-align:left;">
 Body
 </div></div>

Но с переходом на Mediawiki4Intranet такой список становится по умолчанию всегда открытый. Закрыть его можно только нажатием кнопки "Закрыть". При этом он закрывается, но надписи накладываются как показано на рисунке.

Spisok.png

В чем тут может быть проблема? Почему списки стали развёрнутыми по умолчанию, и почему не прячется "Показать"? Можно это как-то поправить?

Такой

<!--
 -->{{#if: {{{1|}}}|<span id="{{anchorencode:{{{1|}}}}}"></span><!--
 -->{{#if: {{{2|}}}|<span id="{{anchorencode:{{{2|}}}}}"></span><!--
 -->{{#if: {{{3|}}}|<span id="{{anchorencode:{{{3|}}}}}"></span><!--
 -->{{#if: {{{4|}}}|<span id="{{anchorencode:{{{4|}}}}}"></span><!--
 -->{{#if: {{{5|}}}|<span id="{{anchorencode:{{{5|}}}}}"></span><!--
 -->{{#if: {{{6|}}}|<span id="{{anchorencode:{{{6|}}}}}"></span><!--
 -->{{#if: {{{7|}}}|<span id="{{anchorencode:{{{7|}}}}}"></span><!--
 -->{{#if: {{{8|}}}|<span id="{{anchorencode:{{{8|}}}}}"></span><!--
 -->{{#if: {{{9|}}}|<span id="{{anchorencode:{{{9|}}}}}"></span><!--
 -->{{#if: {{{10|}}}|<span id="{{anchorencode:{{{10|}}}}}"></span><!--
 -->{{#if: {{{11|}}}|<span class="error">[[Template:Anchor]] (or Anchors): too many anchors, maximum is 10.</span><!--
 -->}} }} }} }} }} }} }} }} }} }} }}<noinclude>
 </noinclude>

Я это видел, что тут работает. Но тоже с особенностями, кнопка Скрыть/Показать внизу, а не справа... А какие-нибудь мысли почему у меня отвалилось это дело есть? Ладно, буду пробовать танцы с бубном.., попробую почистить common.js/сss, ...

А, точно. Да не, чего там чистить. С тем что справа как раз всё понятно — если убрать пробелы из начала строк и перевод строки после <div>, всё нормально становится.

Это как раз одно из того чего фиксили:

  • <div>\nX</div> отпарсится в <div><p>X</p></div> (и кстати например blockquote вместо div — аналогично)
  • <div>X</div> отпарсится в <div>X</div>

Смотри, я поправил.

А почему у тебя отвалилось - скопируй сюда код, на котором отвалилось, и посмотрим.

Ну я и говорю - скопируй сюда код, который отвалился, и посмотрим.

Код такой например

{{Hider|Скрипт для обработки вьюпоинта (для SDL)}}
 <source lang="tcl">
    //
    // ONLY "sdl" - name viewpoint!
    //
 </source>{{Hider|end}}

у меня развёрнут при просмотре на моей Mediawiki4Intranet

Хм. Странно, сам по себе действительно не отваливается. Нужно смотреть что там ещё есть в этой статье... Что-то там не слава богу.

Собственно говоря, часть, ответственная за дивы, в нашей сборке мало отличается. Так что вряд ли проблемы с Common.css и Common.js.

Выкинул содержание MediaWiki:Common.js, заработал Hider. Common.css оставил, чтобы рамку рисовал вокруг списка.

А, ё-моё, у тебя свой Common.js был прописан... У нас-то он в комплекте поставки в CustisScripts...

Заметил, что файлик skins\custis.php имеет перевод строки как в виндовс (0D 0A), сильно бросается в глаза... Конечно не критично, и наверно, не повлияет ни на что...

CustisSkinCRLF.png

Ага, ни на что не влияет, но для порядка поправил.

В mediawiki для формул используется тег <math>, а в Wiki4intranet просто <m>, причем стандартный тег по умолчанию отключен. Получилось при подключении старой базы к новому движку отвалились все формулы... Как предлагаете решать эту проблему?

  • включить $wgUseTeX = true;. Не будет ли в этом случае каких либо конфликтов?
  • подправить расширение MarkupBabel, добавить 'math' => 'amsmath'. Правда, по формату не уверен есть ли полная совместимость.
  • поменять текст на страницах, заменить <math> на <m>, но как это сделать автоматом пока не представляю.

Завтра буду пробовать, что получится из этих вариантов...

По предложенным путям решения:

  1. Так ничего не заработает, т.к. $wgUseTeX требует специальную тулу "texvc", которую собрать под винду - отдельная задача, это раз, и которая на самом деле нафиг не нужна для рендеринга латеха, это два. Собственно, поэтому у нас латех и сделан по-своему. И, кстати, наш MarkupBabel круче ещё и тем, что рендерит TeX-формулы в векторном виде. Кстати... А не забыл ли я написать на странице MediaWiki4Intranet про dvisvgm, для этого требуемый? Проверю...
  2. С точки зрения совместимости - самый нормальный путь решения. Наверное, даже имеет смысл поправить MarkupBabel у нас. По формату полная совместимость - латех он и есть латех.
  3. Воот, а для этого у нас есть специальный инструмент :) Special:BatchEditor ("Массовая правка страниц" в спецстраницах)

1. у меня это заработало. Я под линуксом это дело подымаю, в старой вики texvc был, я его и заюзал. Но с <m> не помогло, см. ниже коммент.

Проги dvisvgm у меня не стояло...

Остальное ещё смотрю...

Ну да, если texvc уже был, то логично. Я к тому, что так бы тех под виндовой сборкой не работал, а он у нас там нужен...

2. С точки зрения совместимости - самый нормальный путь решения. Наверное, даже имеет смысл поправить MarkupBabel у нас. По формату полная совместимость - латех он и есть латех.
Судя по последней сборке вы в MarkupBabel не дописывали math? Приходится после обновления дописывать самому...

Нет, дописал, но он включается, только когда $wgUseTex = false, чтобы не конфликтовать со стандартным мэтодом.

Виноват, не досмотрел.. Верней смотрел, но не туда... Всё работает, спасибо.

Что-то мне везёт... Всё началось с исчезновения 10ГБ места, что привело к вешанию mysql. Поиск виновника привел к файлу

ls -l /var/log/apache2/error_log -h
-rw-r--r-- 1 root root 18G Ноя 24 10:37 /var/log/apache2/error_log

После его удаления я не долго радовался свободному месту на диске, так как в скором времени этот файл снова вырос. Оказалось, что при использовании на странице тега для вставки формулы, например, <m>sdfgd</m> этот файл увеличивается на 1.8ГБ. Сообщения в нём такие:

При этом файлик для latex`а и картинка png в папке images/generated/amsmath/... создаётся. В общем, трудный переход у меня получается на Mediawiki4Intranet...

Ну понятное дело :) вы влезли в неоттестированную область - переход со стандартной вики на нашу :) зато много нового узнаёте :) (UPD: а мы много багов исправляем)

Хм. Эта ошибка, кстати, возможно связана именно с отсутствием dvisvgm (см. коммент выше). Наверное, оно пытается рендерить вектор, у него не получается, и оно сваливается на несуществующем файле. Но да, поправить её надо. Это весь лог такими сообщениями забит?

Не 1.8Гб, а 18Гб, наверное? Вообще, лично я как-то привык везде работать с показом PHP-ошибок в браузер, а не в лог апача, кстати. Его всё равно редко кто читает, а так все ошибки сразу видны. Ну и место не забивается.

Лог на 1.8ГБ увеличивался за 1 нажатие на предпросмотр, при этом страничка не появлялась...

Поставил dvisvgm - проблема исчезла, формулы появились. Буду смотреть дальше, что ещё не так... ))))

"Это весь лог такими сообщениями забит?" - Я все 1.8ГБ не смотрел, но последних несколько сотен строк такого плана.

Интересно, что случится с браузером, если в него 1.8ГБ ошибок направить...))

Вот ещё сообщение из лога, почему-то в корень лезет за иконкой

[Thu Nov 24 13:19:06 2011] [error] [client 172.17.4.37] File does not exist: /var/www/localhost/htdocs/favicon.ico

Путь в BaseSettings.php задан не существующий файл.

$wgFavicon = "$wgScriptPath/custisinstall/favicons/wiki4intranet.ico";

А $wgFavicon=/favicon.ico задано в настройках по умолчанию, но проблема, что если я меняю путь $wgFavicon к существующему файлу, то проблема не решается...

И ещё непонятная штука вылезает

[Thu Nov 24 13:39:16 2011] [error] [client 172.17.4.37] File does not exist: /var/www/localhost/htdocs/share, referer: http://172.17.4.37/wiki4intranet/
  index.php?title=MediaWiki:Monobook.css&usemsgcache=yes&ctype=text%2Fcss&smaxage=18000&action=raw&maxage=18000
  • Эх чёрт, забыл wiki4intranet.ico подложить, теперь историю не поправишь :)
  • Ну проверь, у тебя на MediaWiki:Monobook.css ничего не написано?
  • MarkupBabel поправил, doBlockLevels поправил, после элемента списка теперь преформатирование должно работать, сборку обновил.

Не работает под PHP 5.2.8 на OpenSUSE 10.2. Валит ошибки на функционал, появившийся в PHP 5.3. Например:

- на оператор goto
- func_get_args(): Can't be used as a function parameter

Хм. Спасибо за замечания. Поправим.

Поправил, обновил сборку. На заметку: маркированные списки в mediawiki делаются с помощью * в начале строки :-)

Так себя должны вести картинки в разных форматах? В PNG формате LaTeX2e.png вставляться, центрируясь по вертикали, а в SVG формате Symbol thumbs up.svg вставляются как буквы, лежат на строке.

Да... Сам тоже замечал, но почему-то не исправлял. Не знаю, почему, vertical-align: middle на них отлично работает, щас проверил :-)) поправлю))

(Разница в том, что у нас SVG вставляется как SVG, а не растеризуется, как в обычной вики)

Надеюсь я ещё не сильно вам надоел со своими вопросами... Вот ещё одну особенность обнаружил. Если загрузить картинку SVG в вики, а затем добавить новую версию этого рисунка, но уже в формате PNG, то похоже система воспринимает новый png-рисунок за svg-текст... Вот пример Media-playback-start-red.svg, у меня эта страница выглядит так:

Bug svg png image.png

Зачем надоел, мы тут наоборот радуемся, что нас тестируют :-)

А в смысле - загрузить новую версию того же файла, но PNG - это как вообще? Ты в качестве svg png'шку загружаешь (и под именем .svg)? А чего ты ждёшь от вики в таком случае? :-)

А почему нельзя загрузить новую версию рисунка в другом формате? У меня, честно говоря, и мысли не было, что так делать не правильно... И предупреждений вроде не вылазило никаких... Ладно, теперь буду учитывать на будущее...

Ну не знаю, вообще-то это логично, что "File.svg" это SVG, а не PNG.

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

Проверил - у нас была отключена проверка MIME-типов при загрузке файла из-за того, что какое-то время назад (возможно, даже ещё в 1.13 - 1.14) совсем неправильно определялся тип Visio-документа как Word'овского, и соответственно не получалось его загрузить под расширением .vsd вообще.

Сейчас уже стало лучше (определяется как vnd.ms-office), поэтому запатчил файл с сопоставлением расширений MIME типам, и включил проверку обратно. Теперь PNG поверх SVG загрузить не даст :) сейчас только сборку ещё обновлю.

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

Насчёт меньше - не будем точно, т.к. при установленном в браузере увеличенном шрифте будет вообще мизерно. Сейчас по-моему вполне соответствует стандартному.

Насчёт вертикального выравнивания - да, разумное замечание. Постараюсь исправить.

"Насчёт меньше - не будем точно" - хотя бы скажите, где это можно поправить?

Я даже сходу и не скажу. Это нужно чтобы тех больше картинку делал на выходе. А кинь скриншот, что тебя так сильно расстраивает, что ты их уменьшить хочешь?

выглядит так

Math in text.png

Слишком крупные формулы внутри абзаца получаются... Большие интервалы между строк получаются и абзацы уже смотрятся не так...

Центрирование тоже смотрится не очень, тут нужно различать:

  • формула без индекса
  • формула с нижним индексом
  • формула с верхним индексом
  • формула с нижним и верхним индексами

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

Варианты формул.png

Может параметр ввести в <m> для задания смещения по вертикали, или html-разметка такое не позволяет делать?

Да это-то понятно. Просто где её взять-то, базовую линию. Мне вот интересно, как то же самое в оригинале mediawiki рендерит?

На википедии выглядит так

Wikipedia-math-example.png

У них простые индексы в формулах кодируются простой html-разметкой, а формулы вставляются центрируясь по вертикале.

Ну, простые индексы-то понятно, их всегда так можно написать. Вертикальный отступ задавать можно, но руками это делать - по-моему грустное занятие будет... Вот если бы найти способ узнать положение baseline в результирующей svg'шке...

Наверно можно Latex попросить, чтобы выдал baseline каким-либо образом..

Ещё была проблема с названием. Изначально, название "Quiz:Тестирование по смешанному моделированию" не проходило, т.е. не появлялись в начале страницы ссылки "Пройти тест" и др. Пришлось поменять название на более короткое "Quiz:Тест", тогда ссылки появились. С чем это может быть связано?

Это с длиной. Там зашита длина ID теста <= 32 символа.

Раз не появлялось вообще ничего, значит ошибки PHP, которые, насколько я помню, у вас сыплются в лог, а не на экран. Так что в лог и смотрите.

Ошибки такие:

Strict Standards: Non-static method MediawikiQuizzerPage::checkAnswers() should not be called statically in
/var/www/localhost/htdocs/mediawiki4intranet/extensions/mediawikiquizzer/mediawikiquizzer.class.php on line 892

Fatal error: Class 'Imagick' not found in /var/www/localhost/htdocs/mediawiki4intranet
/extensions/mediawikiquizzer/mediawikiquizzer.class.php on line 1174

Чтобы заработал класс Imagick в Gentoo поставил дополнительно пакет dev-php/pecl-imagick. После этого финальная страница появляется, но ошибки ещё остались:

Strict Standards: Non-static method MediawikiQuizzerPage::checkAnswers() should not be
called statically in /var/www/localhost/htdocs/mediawiki4intranet/extensions
/mediawikiquizzer/mediawikiquizzer.class.php on line 892

Notice: Undefined variable: html in /var/www/localhost/htdocs/mediawiki4intranet
/extensions/mediawikiquizzer/mediawikiquizzer.class.php on line 1273

Доброго Вам утра.

Большое спасибо за классный продукт! Это первое :)

Второе - уже на второй машине, где я пытаюсь поставить Windows-сборку, не работает экспорт статей. С однотипной ошибкой: создается файл {My+MediaWiki+Name}-DateTime.zip (но на самом деле это текст с wiki-разметкой) следующего содержания:


---cut here----------------------

<br /> <b>Warning</b>: readfile(D:\temp\exp2BE.tmp/archive.zip) [<a href='function.readfile'>function.readfile</a>]: failed to open stream: No such file or directory in <b>D:\wiki4intranet\htdocs\wiki\includes\specials\SpecialExport.php</b> on line <b>211</b><br />

---cut here----------------------


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

Заранее благодарен за помощь.

И вообще, интересно следующее:

  1. характерна ли данная проблема только для меня?
  2. если не только для меня, то характерна ли данная проблема только для Windows-сборки?

О, спасибо. Да, проблема в Windows-сборке - отсутствуют утилиты zip и unzip. Добавим, исправим, сборку обновим.

Чтобы исправить самому - скачайте zip, unzip и bzip2 для винды, распакуйте куда-нибудь (только в один каталог, а то bzip2.dll нужен утилите zip) и это куда-нибудь пропишите в свой LocalSettings.php так:

$wgZip = "...путь\\zip.exe";
$wgUnzip = "...путь\\unzip.exe";

У нас сейчас, на самом деле, в процессе обновление MediaWiki до 1.18.1, и следующая выложенная сборка, в которой этот баг будет исправлен, скорее всего будет уже 1.18.1.

По поводу второй проблемы текущей Windows-сборки - с ошибкой PHP:

Php imagick problem.png

В прошлых сборках у нас были везде гвоздями забиты пути D:\wiki4intranet\. В последней я это обнаружил и везде поубирал, а также решил добавить ImageMagick, которого там раньше, опять-таки, вообще не было. Но для его загрузки нужно менять переменную окружения PATH - пришлось расхачить xampp_control и научить его прописывать туда пути из xampp.ini, а xampp_start.exe и xampp_stop.exe поменять на батники.

Но хе-хе, расхачить расхачил, а потом случайно оставил там путь с F:\ :) короче говоря, просто уберите F: из xampp.ini, если он там есть...

« first ‹ previous 100 ... last »

Please login to comment.

2016-09-09 MediaWiki4Intranet — развертываем для разработки и в production c помощью Vagrant и Ansible

Как быстро бежит время! Проекту MediaWiki4Intranet уже больше десяти лет, а нашим попыткам натягивать сову на глобус MediaWiki для всех интранет-задач внутри IT компании и вовсе лет 12.

И изначально все было достаточно просто и понятно — стандартный PHP-проект, в духе «скопируй файлы в настроенный PHP-хостинг». Было не зазорно вести разработку/доработку в винде, под LAMP-окружениями типа XAMPP, а на линукс-машину выкатываться через SVN.

Поэтому мы в свое время и завели такую штуку, как Windows-сборка Mediawiki4Intranet, где обычным каталогом лежали все необходимые утилиты/фреймворки (включая TeX, Graphviz, Sphinx), и любой виндовс-пользователь мог попробовать нашу вики, и даже, не приходя в создание, править и создавать какие-нибудь расширения[1].

Но время идет.

MediaWiki из моностекового монолитного PHP-проекта, с классической моделью «генерация страницы на сервере» постепенно превращается в мультистековый микросервисный проект с realtime UI — так, например, появившийся WYSIWYG-редактор требует специально поднятого сервиса на node.js. На подходе даже мгновенное коллаборативное редактирование в стиле «etherpad/googledocs»…

Все это уже не развернуть тупым копированием файлов, и нереально влом тащить все это под Windows — к тому же, почти все вменяемые вебразработчики ушли на Mac/Linux. Впрочем, современные тренды разработки вовсе требуют вынести за скобки систему разработчика (все это холиварно и его личное дело), а все-все-все зависимости проекта инкапсулировать и виртуализировать/контейнеризировать[2]. Т.е. все, полноценная MediaWiki — больше не проект для shared hostingа[3], но и shared hosting уже почти умер для нормальных проектов. Если кто не в курсе, то цены на изолированный VPS-контейнер упали уже совсем ниже плинтуса[4], и разница в плате за «VPS vs Shared» уже давно не проблема.

Проблема остается только в сложности разработки и обновления нашего «бандла» — как его ставить, чтобы можно было в пару действий, с минимальной кривой обучения

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

Именно для этого, мы в свое время сделали инструмент Repo.php, специально заточенный для развертывания MediaWiki4Intranet, но…

  • Он все-таки про развертывание PHP-части, где-то конкурируя с Composer[5]
  • Развернуть и раскатать систему с нуля, поставить nod-ный стек, настроить firewall и т.п. — за пределами его функциональности.
  • Никто уже не хочет слышать ни о каких новых, и тем более самопальных системах развертывания, когда DevOps-зоопарк уже взрывает всем мозг, а горшочек все продолжает варить и они все лезут и лезут на свет.

Поэтому, мы взяли все самое распространенное-стандартное-проверенное:

  • Vagrant — для эффективного руления локальными машинами.
  • Ansible — для декларативной конфигурации сервера на «Centos 7»[6]-машин. Чтобы с одной стороны, больше никогда не опускатся до простыней инструкций в духе «отредактируйте /etc/xxx, заведите каталог /var/log… ×100500 …», с другой — все это легко читаемо и понимаемо даже теми, что впервые слышит про ansible.

Т.е.

  • Почти ничего учить не придется.
  • Если что и придется — это полезные знания, уже ожидаемые от ITшников.


Итак, допустим, что у вас здоровая Linux-система[7]. Ставите:

Vagrant
пакетным менеджером или просто RPM/DEB с сайта.
Ansible
пакетным менеджером или, если вдруг он в вашем дистрибутиве очень старый или его нет — через «pip install ansible».
VirtualBox
обязан быть в пакетах, но если нет — можно и с сайта.

Дальше:

 git clone git@github.com:mediawiki4intranet/mediawiki4intranet-vagrant-ansible.git
 cd mediawiki4intranet-vagrant-ansible
 vagrant up


Пока идет развертывание, прописать в /etc/hosts

 127.0.0.1 intrawiki.local.com


Все должно кончится хорошо, без страшных слов о падениях и красной раскраски терминала. Только желтые и зеленый цвета и что-то типа

PLAY RECAP   
*********************************************************************                                                 
intrawiki                  : ok=468  changed=132  unreachable=0    failed=0     


Для очистки совести можно спросить:

vagrant port                                                        

и убедится, что форвардинг, какой-то такой:

 22 (guest) => 2222 (host)               
 80 (guest) => 15304 (host)                
 3306 (guest) => 15305 (host)

Т.е. вы получаете SSH доступ к машинке по 2222 порту, доступ к MySQL базе по 15305, ну и можете просто открыть в броузере http://intrawiki.local.com:15304/ — там вас ждет настроенная MediaWiki, с почти всеми нашими расширениями, Sphinx-поиском, IntraACLем и WYSIWYG-редактором.

Там много-много всего хорошего, я только упомянул самое главное —

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

Итак, логиньтесь туда админом-бюрократом WikiAdmin/Wiki1729Admin, и делайте все что угодно.

Все настроено и работает! Ну, должно работать. It works on my machine, шучу, проверял на нескольких.


Да, когда таких локальных виртуалок становится много, возникает путаница с портами, лень подключать/отключать файловые системы, и в результате, я написал некий набор утилит, которые решают эти проблемы:

  • сами монтируют файловые системы активных vagrant-машин,
  • позволяют SSH-логинится по имени vagrant-машины,

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

Можно зайти туда по SSH:

vagrant ssh

или

ssh vagrant@0 -p 2222

или

ssh root@0 -p 2222

Можно смонтировать всю файловую систему по sshfs

 sshfs root@0:/ -p 2222 -o reconnect /mnt/intrawiki

Разумеется, проверьте («vagrant port»), что у вас именно 2222 SSH-порт и заведите каталог для монтирования (/mnt/intrawiki или где вам удобно).


И локально настроенная машина уже готова к PHP-отладке — если ваше IDE умеет PHP-xdebug-отладку — просто включите его слушать 9000 порт, и отладка пойдет, вам только стоит отмаппировать выполняемые PHP-файлы на подмонтированную по SSH файловую систему (об этом обычно спрашивает само IDE[8]).


Ну а если хотите выкатывать наружу, правите hosts.ini, указывая IPшник и sudo-пользователя вашей VPS[9], нужный домен и название сайта, и запускайте !intrawiki-production.



Ну, а теперь разьяснение, что и где, и зачем.

Vagrantfile
Настройки локальной виртуалки. Тут что-то менять необязательно. Хотя можно вместо монтирования по SSH сделать разделяемую папку, можно рулить выдаваемым CPU и памятью, можно сменить порты. Тут же можно отключить отладочность локальной инсталляции — может вам нужна именно производительная локальная вики для работы, а не разработки.
hosts.ini
как деплоить production-сервер, тут настраивать обязательно. Не забудьте сменить пароль к WikiAdmin, а то я приду и взломаю вас :).
group_vars/all
Настройки-константы, определяющие куда все это встанет, и в крупноблочно — что. Так, установив «tex: no», если вам не нужны формулы и поддержка LaTeX-разметки, можно отказаться от жирного TeX-стека, а задав «wysiwyg: no», отказаться от WYSIWYG-редактора VisualEditor, и жирного nodejs-стека. Кстати, пока они не очень хорошо живут вместе — WYSIWYG-редактирование может убить «latex»-блоки.
roles
Сконфигурированные ansible-роли.
roles/common-root
Общие настройки минимальной центоси до более-менее вменяемой, куда будут заброшены ваши публичные ключи для беспарольного входа. Да, мы потрогаем ваш приватный ~/.ssh/id_rsa, но честно-честно, никуда его не унесем, только вытащим публичный ключ чтобы облегчить авторизацию на вики-серверах.
roles/parsoid
Развертывание nodejs-сервиса парсинга — если не нужно WYSIWYG-редактирование, можно исключить настройками в group_vars/all.
roles/wiki-root-common
Настройка PHP-NGINX-PHP-FPM стека, общего, если вы заходите держать несколько вик.
roles/intrawiki-root
Настройка конкретной вики (если нужно несколько вик, можно копировать-настроить этот каталог). Основные тонкие настройки там:
  • В roles/intrawiki-root/tasks/main.yml найдете список расширений и откуда их брать. На простые бинарные настройки это не высадить, особенно если вы будете форкать расширения, или наоборот, фиксировать версии. По смыслу там все понятно. Откуда брать, куда ставить, какая версия. Если расширение потребует дополнительных библиотек через composer — они поставятся. В общем блоке LocalSettings сделано так, что автоматически подключаются все установленные расширения. Т.е. если вам что-то ненужно — просто удалите и не выкачивайте расширение. Если нужно что-то еще — просто добавьте
- include: templates/install_ext.yml item={{ item }}
  with_items:
  - {dest: '',         url: '{{prefix_github}}mediawiki4intranet/core',     version: mediawiki4intranet-core-1.26}
  - {dest: 'config',   url: '{{prefix_github}}mediawiki4intranet/configs',  version: master}
  - {dest: 'vendor',   url: '{{prefix_wikimedia}}vendor',  version: REL1_26}
  - {dest: 'extensions/googleAnalytics',   url: '{{prefix_wikimedia}}extensions/googleAnalytics',  version: master}
  - {dest: 'extensions/MediaFunctions',    url: '{{prefix_wikimedia}}extensions/MediaFunctions',  version: master}
…
  - {dest: 'skins/cleanmonobook',  url: '{{prefix_github}}mediawiki4intranet/skins-cleanmonobook',  version: master}
  - {dest: 'skins/vector',  url: '{{prefix_github}}mediawiki4intranet/Vector',  version: mw4i-1.26}
  - {dest: 'skins/monobook',  url: '{{prefix_github}}mediawiki4intranet/skins-monobook',  version: mw4i-1.26}

Ну вроде и все — проект этот будет поддерживаться в актуальном состоянии, будем добавлять новые роли и возможности, стараясь при этом чтобы все это не стало монструозным.

«Присоединяйтесь, барон!» © — ставьте, пользуйтесь, пишите новые интересные расширения.


  1. Вот короткая, почти не устаревшая лекция про архитектуру MediaWiki
  2. Самый последний писк моды это «ехал докер через докер»™, но сейчас мы рассмотрим олдскульный подход, с виртуальными машинами и гибким обновлением через ansible. Докер тоже будет. Но потом.
  3. И не надо к нам больше обращаться с просьбой развернуть все это за две тыщи рублей на шаредхостинге!
  4. Хоть за пару баксов в год
  5. Который, кстати, появился слишком поздно, после Repo.php — иначе бы, конечно, не стали бы так «велосипедить»
  6. «Centos 7» — наиболее популярный в «энтерпрайзе» серверный линукс, какой бы дистрибутив вы не любили, и как бы вы не относились к редхатоподобных дистрам
  7. Если у вас Windows, попробуйте путь с cygwinом-babunом
  8. Лично я люблю Komodo IDE
  9. Ожидается VPSка с свежеустановленной Centos 7 — все хостеры VPS предоставляют такой шаблон

2014-10-31 Копипаст документов (и даже картинок) из Word'а

Раньше, когда в Wiki по умолчанию был включён wikEd, многие его использовали исключительно для вставки форматированных текстов из Word’а / OpenOffice / LibreOffice / просто из браузера.

Однако уже с прошлого года wikEd по умолчанию выключен (Блог:TechTools/2013-07-11 А не выключить бы нам wikEd?), и функцию копирования текстов я уже тоже довольно давно переместил на «нормальную» панель редактирования (WikiEditor). Вот эта кнопка:

Wikieditor-word-copypaste.png

При её нажатии появляется «окно», в которое нужно путём Ctrl-V скопировать текст из Word/LibreOffice, после чего нажать «вставить», и Wiki (ну, не сама MediaWiki, а конкретно кусок кода, взятый из wikEd’а), как умеет, сконвертирует текст в свою разметку и вставит в поле редактирования страницы.

А теперь о новой фиче, добавленной недавно: в данную функцию я добавил поддержку автоматической загрузки изображений!

Просьбы реализовать такое поступали довольно давно, но раньше я думал, что это невозможно, так как при вставке из буфера обмена в contenteditable элемент в браузере изображения теряются. Однако, недавно я обнаружил, что если копировать текст из LibreOffice (не OpenOffice и не Word!) в Firefox, изображения сохраняются! В виде <img src="data:base64,..." />, то есть, содержимое вставляется прямо в копируемый текст в виде base64-кодированной строки. А раз изображения там есть, значит, и поддержку запилить можно :)

Так что теперь, если вы вставите в появившееся окно из LibreOffice текст, содержащий картинки, и нажмёте «вставить», справа появится их список с предложенными названиями:

Wikieditor-word-copypaste-imagelist.png

Здесь нужно выбрать желаемые названия и нажать «Загрузить». Изображения загрузятся и заменятся в тексте на соответствующий вики-код, и снова появится кнопка «Вставить», после нажатия которой текст уже вставится в статью. Либо, если вы не хотите загружать какие-то картинки — нажмите «Отменить», удалите их из текста прямо в окне, в которое делали копипаст, и нажмите «Вставить» снова.

Загружаются изображения в том же виде, в котором их передаёт LibreOffice, без снижения качества, а в статью вставляются в приблизительно том размере, до которого были отмасштабированы в документе.

Вот такая у нас теперь есть интересная фича :)

2013-11-13 Автокомплит в вики :-)

Как мы все прекрасно понимаем, сила MediaWiki и вики-системы в целом обычно основана на редактировании некой текстовой разметки.

А где текст — там обычно и автодополнение :-) но раньше я был уверен, что получить положение курсора в голом браузерном поле ввода невозможно, поэтому автокомплита в вики не было :-(. Однако недавно пришло осознание, что через определённый костыль это всё-таки реализуется! И подобный костыль даже используется github’ом.

Так что встречайте! На все наши вики установлено запиленное в последнее время расширение, подсказывающее ссылки, шаблоны, функции парсера и даже секции статей! :-)

Я подозреваю, что особенно оценят эту фичу программисты, привыкшие к IDE. ;-)

Ссылки, файлы, категории Секции статей Шаблоны Функции парсера
Mw-suggest-link.png Mw-suggest-sections.png Mw-suggest-template.png Mw-suggest-pf.png

Также оно понимает относительные ссылки и включения шаблонов ([[../Страница с того же уровня]], [[/Подстраница]]).

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

Плюс ещё нужно подсказывать функции парсера, которые пишутся без #, то есть выглядят примерно так же, как шаблоны. Тут минус в том, что оно будет с шаблонами, собственно, перемешиваться. Но и то, и другое, я думаю, реализую чуть позже.

2013-05-21 Новые фичи в ВикиПрезентациях

S5MW.svg

Есть у нас такое расширение MediaWiki — S5SlideShow. Нами написанное, на S5 основанное, и позволяющее легко, быстро и удобно генерировать презентации, просматриваемые прямо в браузере, из вики-статей.

Главные преимущества S5 в том, что:

  • Можно использовать весь спектр возможностей Wiki — всякие картинки/SVG, графы, подсветку кода и так далее, вплоть до видеороликов или MindMap’ов.
  • Можно писать дуальную «статью-презентацию», перемешивая слайды и НЕ-слайды.

В итоге такие статьи, в отличие от голых PPT’шек, валяющихся непонятно где на сетевых дисках и/или на всяких левых slideshare, содержат куда больше смысла и остаются полезными и через год, и через два после показа.

Так вот, теперь кроме обычного просмотра появилась ещё и возможность печати и/или PDF-экспорта (через печать в PDF-файл) любой презентации! PDF-принтер в Linux’е есть в наличии всегда, а под виндами ставится в куче реинкарнаций — например, через Ghostscript.

Инструкция по печати есть здесь: Печать и PDF-экспорт.

Делается в Firefox (можно также Chrome) с помощью вот этой кнопки, которую можно увидеть, подведя курсор мыши к правому нижнему углу страницы в режиме презентации:

S5-print-btn.png


Статья реплицируется в Wiki4IntraNet.

2011-12-30 Lightbox в вики

UPDATE: Расширение установлено, и тут же заюзано HR'ами в Фотоотчёте по стажировке 2012.

Что такое lightbox и его аналоги, наверное, все уже знают:

WikiLightbox.png

Я тут ночью откопал полудохлое кривое расширение вики SlimboxThumbs, переписал его нафиг с наикривейших регэкспов на js и поставил себе — получилось неплохо (пример). При клике по миниатюре любой картинки показывает её во всплывающем окне в полном размере. Если полный размер больше, чем 80 % окна браузера, уменьшает до нужного размера. Все миниатюры на странице показываются друг за другом. В lightbox не попадают вставленные без ссылки миниатюры и полноразмерные изображения (типа, куда их ещё увеличивать?) — кстати, может быть как раз это и неправильно, а надо показывать вообще все? Получится что-то типа функционала «просмотр вообще всех иллюстраций к статье в режиме слайд-шоу».

Так вот, вопрос: кто-нибудь имеет возражения против? Поставить расширение к нам?

Нужен ли в вики Lightbox?

Да0
0%
Нет (в комменты — а почему?)0
0%

You must be logged in to vote.

SVGEditor — инфографика и схематизация не выходя из броузера

Полкомпании было у нас на выездной сессии, и вне зависимости от отношения к этому мероприятию, думаю, многие отметили одну из ключевых штук — эффективность простых ad-hoc схем, особенно рисуемых совместно.

Я сильно далек от мнения, что именно «на схемах и развертывается реальная организационно-управляющая мыследеятельность», но соглашусь с тем, что относительная эффективность картинки не обязательно монотонно растет с трудозатратами на ее рисование, более того, рулят именно совокупность простых иллюстраций и схем[1], сопровождаемых устно или текстом, а не простыни текстов и перегруженные «схемы всего».

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

Но тут проблема — многие воспринимают вики только как «совместное редактирование текста», и иллюстрации делают только от большой необходимости, и если уж делают, то трудоемко, «добротно сколоченными в Visio», с кучей cliparta, трехмерностью, и проблемами — как это совместно редактировать и развивать? Ну и вообще, даже если использовать прекрасный свободный векторной графики Inkscape и хранить SVG-файлы в вики, то возникает гемморойность возни с загрузкой файла из-за какой-то простой схемы в пару квадратов.

И тут очередное напоминание, что «вики — это не только ценный мех редактирование текста и Graphviz-диаграмм», но и отличное редактирование в броузере векторных картинок, без возни с файлами и необходимости что-то куда-то инсталлировать[2].

А именно — если вы вставите в текст

[[Файл:Любое название файла с расширением SVG.svg|center]]

то пройдя по ссылке вы сможете его прямо в броузере и редактировать (ссылка «создать/изменить этот SVG-файл с помощью SVGEdit»).

Тоже самое можно сделать и тупо набив имя файла-статьи в URLе, или через загрузку файла — в общем, при любой попытке создать/загрузить SVG-файл, вам предложат его создать, а если он есть — редактировать через SVGEdit.

В редакторе же есть все необходимое для простых схем, и даже больше. Есть даже вполне вменяемый набор шаблонов-stensils (стрелки, фигуры, иконки, символы,…), так что даже несмотря на то, что в рисуя этотим редактором можно грузить SVG изображения из всего интернета[3], простые схемы можно делать вообще не приходя в сознание:

center

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

Поэтому для демонстрации быстроты и эффективности осмысленных схем, я набросал небольшой пост в личный блог: Блог:Стас_Фомин/Адизес,_СМД-схемы_ОРУ_от_БМО,_и_польза_визуализации

Ну, а если нужны какие-то сложные шаблоны и заготовки (например, project specific), то их тоже можно хранить-наращивать в вики, см. например, Категория:Abstract Concepts (Cliparts) и при необходимости импортировать их в новый рисунок, ни разу не обращаясь к локальным файлам, просто копируя URL SVG-файла, и импортируя его в новый рисунок, открытый в соседней вкладке.


Ну и разумеется, как всегда совы не только то, чем они кажутся можно использовать SVGEditor и для всякого разного.

Например, в нем можно вести хитрые статусные доски, см. например, статус работ по видеомонтажу.

Возможно в нем можно будет набрасывать и согласовывать mockup-ы интерфейсов. Есть другие идеи? — пробуйте!


  1. Вам нужна схема? — сейчас я поставлю точку в середине флипчарта…
  2. На самом деле, подобная штука у нас была с незапамятных времен, называлась AnyWikiDraw, но была она апплетом на Java, безбожно глючила и тормозила, и мы ее похоронили, заменив на SVGEditor. Который уже web-native (JS-HTML-SVG), и долгое время тоже был глючноват, но сейчас уже дозрел, по крайней мере, для простых схем, за которые я и агитирую.
  3. Рекомендую http://clker.com в качестве свободных векторных рисунков

Встречайте: лайки, рейтинги и pagerank-и! Теперь и в вики.

right

Good news, everyone! Возможно многие из вас уже заметили новый информационный квадратик, появившийся в навигационном блоке.

Что это и для чего?

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

Действительно,

Web 0.0
Это изначальная задумка Тима Бернса-Ли, которым мыслил интернет как целостный гипертекст, т.е. набор двунаправленно связанных страниц (т.е. всегда можно узнать и «кто ссылается?»). Это по большому счету, не реализовано в распределенном интернете, только индексы крупных поисковиков могут дать некоторый паллиатив (поиск с синтаксисом «link:» в гугле, например). Зато реализовано в вики, где, напоминаю всем, есть полезная ссылка «Ссылки сюда» (сорри за тавтологию), и есть целостный учет, кто ссылается и кого включает.
Web 1.0
Попытка вычислить ценность контента, основываясь на действиях авторов-вебмастеров → учет ссылок, введение различных индексов цитируемости и PageRank-ов, рассчитываемых достаточно приближенно. Этот подход дал взлететь Google, но потом закономерно привел к аду SEO-спама.
Web 2.0
Учет пользовательских факторов — кто читает (сейчас это основной фактор ценности контента в поисковиках, что приходится учитывать очень хитрыми методами), нравится ли это (лайки-рейтинги и т.п.).

Так вот, теперь все это есть и у нас. Благодаря централизованному хранению, ссылочные метрики у нас были всегда, журналы «кто и что читал» мы начали учитывать, ну и дополнительно — мы завели гибридно-гуманные «likes-favorites».

Гибридные
Потому что мы совместили функциональность favorites и likes — нажав на звездочку-астериск в этом блоке, вы одновременно добавляете страницу в свое «избранное», доступное по одноименной ссылке, и этот факт учитывается в рейтинге статьи. Нам не хотелось бы разделять эти понятия, чтобы не было «накруток» статей, не представляющих на самом деле интереса для оценивающего. А так все просто — «полезное тебе» → «добавляй в избранное».
Гуманные
Нет «dislikов» и прочих «-1». Ибо мы декларируем гуманный и конструктивный интранет, и очень не хотим повторения с ОИГ[1], и в случае несогласия «-1» недостаточно, лучше предложить альтернативное мнение, которое, возможно, соберет плюсики.

Итак, конкретно, мы меряем и визуализируем три параметра возможной ценности статьи, которых мы показываем и в игровом стиле — «полосками уровня ресурсов», и, при наведении, конкретными цифрами.

А именно:

Просмотры
Зеленая[2] полоска. Число просмотров статьи (неуникальных), некий обобщенный рейтинг, насколько эта страница востребована. Что касается конкретных читателей, то ведется «журнал посетителей» (по ссылке «журналы»), что более-менее поможет ответить на вопросы «ознакомились ли эти лентяи (или конкретный сотрудник) с трудом комитета по XXX», и наоборот, не читал ли кто случайно, из-за ошибки с правами, что-то для него секретное.
Избранное
Розовая полоска. Число добавлений в избранное, о чем мы уже написали. Если эта страница уже в вашем избранном, то астериск в левом углу тоже будет розовый, если нет — серый. Добавить и удалить из избранного можно одним кликом по этой звездочки.
Ссылки сюда
Число ссылающихся (ссылками или включением) статей. Метрика относительная, но если эта полоска непуста, то надо серьезно подумать, перед тем, как удалять, и даже переименовывать статью.

Что касается длин полосок, то они связаны с соответствующей метрикой не напрямую, а логарифмически — полная полоска наберется для 100000 просмотров, 100 избранных, и 100 ссылок соответственно.

Почему логарифмически? Куча причин. Можно вспомнить и логарифмическую зависимость реакции человеческих органов чувств, и логарифмичность индексов цитирования и прочих PageRank (который, несмотря на сложный алгоритм, для большинства случаев можно заменить логарифмической зависимостью от числа простых ссылок), и неравномерность машинного представления float-ов — ведь тут, в первую очередь нужно не сравнивать «очень крутые статьи» между собой, а выделить статьи, ценность которых показана хоть тушкой, хоть чучелом хоть чем-то — читателями, избранным, или ссылками.


Все это нам дает еще один механизм структуризации-приоритезирования контента на основе быстрой обратной связи (без редактирования и написания текстов).

Например, теперь можно:

Wikilog ratings.png
  • «Плюсовать» в форумах. Для этого в викилогах сделан отдельный интерфейс добавления в избранное, ссылка «+1», и показ набранного количества плюсиков-избранных (похоже на какой-нибудь хабр, но без минусования).
    • Это поможет вам выбрать наиболее конструктивные и правильные с вашей точки зрения мнения.
    • Поддержать участников дискуссии, показав, что их мнение важно читателям. (А то дискуссия кончится черной дырой «пойдет перетрем устно»).
    • Мы планируем сделать дополнительную сортировку комментариев по числу «плюсов» — это немедленно даст для форумов функциональность внутреннего stackoverflow.com — системы типа Q&A, когда к верху «всплывают» наиболее разумные ответы (при том, что сохраняются все варианты и предложения).
  • Возможно аналогичный механизм сортировки будет полезен и в категориях, или в механизме динамически формируемых списков («Top-10» самых ценных статей из категории XXX).

  • Возможно будет интересно лайкать друг-друга, открывая перспективные возможности социального взаимодействия…

Если есть другие идеи, варианты, замечания — предлагайте!


  1. «Октябрьский инцидент с голосованием» См. Блог:Володя_Рахтеенко/2009-11-02:_Голосование_за_семинары, Блог:Стас Фомин/2009-11-06/Голосование
  2. Почему именно такая палитра? Мы взяли ее из разработанного нами логотипа нашего open-source проекта http://wiki.4intra.net/. Почему этот логотип такой — это отдельная история, спросите, если хотите знать.

2012-02-27 Mediawiki4Intranet 1.18

Сегодня версия MediaWiki, лежащая в основе MediaWiki4Intranet, была окончательно обновлена до версии 1.18.1 (предыдущая версия была 1.16.2). Автономная Windows-сборка также обновлена.

С точки зрения пользователя изменений, как всегда, немного; по коду, как всегда, значительно :) журналы изменений MediaWiki можно почитать тут: 1.17, 1.18. Одно из важных изменений по коду, кстати — это ResourceLoader и изменение порядка загрузки javascript’ов. Может коснуться вас, если вы как-то дописываете оные.

С точки зрения конкретно нашей сборки — исправлена приличная кучка багов совместимости расширений с 1.18, патчи обновлены, где-то 3 мелких патча выкинуто. Под виндовой сборкой был даже один segfault :) также исправлены и баги предыдущей Windows-сборки, а именно, отсутствие утилит zip и unzip и ругань на неизвестную библиотеку CORE_RL_wand_.dll.

Предложения по расширению возможностей Mediawiki4Intranet

Предлагается в этом форуме размещать предложения по расширению возможностей Mediawiki4Intranet.

→ continue reading...

2012-01-12 Обновлена Windows-сборка

Обновлена Windows-сборка Mediawiki4Intranet.

Инджой. :)

2011-12-22 Вставка списков багов в вики

Раньше списки багов из Bugzilla в Wiki можно было вставлять только из-под специального юзера «чтонибудьwiki@custis.ru» с тривиальным паролем. Причём сначала ему нужно было дать права на эти баги, потом из-под него сохранить запрос поиска и дёргать его из wiki по имени — {{#buglist:custiswiki|ИмяЗапроса}}.

Однако, и неудобно, и права портит.

Новый способ:

{{bz-embed|url=скопированный адрес}}

Причём можно вставлять как списки багов, так и отчёты. Например:

{{bz-embed|url=http://bugs.office.custis.ru/bugs/buglist.cgi?cmdtype=runnamed&namedcmd=My%20Bugs}}
{{bz-embed|url=http://bugs.office.custis.ru/bugs/report.cgi?x_axis_field=product&y_axis_field=bug_status&z_axis_field=&query_format=report-table&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=exact&email1=%25user%25&format=table&action=wrap}}

Как это выглядит — смотрите Bz-embed-demo. Сделано через шаблон bz-embed. В старых браузерах не работает.

Enjoy :)

Вопросы по расширению MediawikiQuizzer

Что-то пару дней не был доступен сайт Mediawiki4Intranet, а появился актуальный вопрос. Сделали мы тест для проверки знаний и заметили такую особенность, что если при прохождении теста ответить на все вопросы правильно, то страничка с результатом не появляется (вообще ничего не показывается - чистый лист в браузере, после нажатия кнопки отправить ответы). И в списке пройденных тестов данная попытка пользователя никак не отмечается. Если же есть хотя бы одна ошибка, то всё в порядке, после прохождения теста выводится результат.

Такое ощущение, что когда все ответы правильные она хочет что-то особенное показать, а этого не находит и в результате чистый лист...

Ещё в процессе массового тестирования заметили такой момент, что если не представляться системе (не логиниться в пользователя вики), то всё же при 100% правильных ответах выдаётся результат, и попытка фиксируется в логе.

Вопросы по установке Mediawiki4Intranet

При установке в свою систему (Gentoo линукс) сборки Mediawiki4Intranet, взятой здесь, возникло несколько проблем, которые без посторонней помощи не удаётся решить.

→ continue reading...

Заверните мне статью, пожалуйста!

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

Для таких случаев в рунете сложился единый и нерушимый паттерн: «Засунуть в Ворд». Последствия пиратской эры — убежденность, что MS Word есть у всех (у нищебродов и красноглазых линуксоидов есть OpenOffice и LibreOffice), и таким образом, «Ворд» стал универсальным медиаконтейнером. Так например, если кому-то надо послать скриншот — скриншот делается кнопкой PrintScreen, создается Word-документ, картинка копипейстится в документ, документ посылается. Иногда ворд-документ создают, только чтобы скопипейстить в него и затем распечатать.

Подход универсальный, вшитый уже у многих в BIOS, но далеко не оптимальный.

Текстовые процессоры — Word/Writer/… нужны только для одной задачи — сделать бумажный документ, который (увы, ограничение такого носителя как бумага) разбит на страницы. Откуда возникает куча проблем с оптимальной версткой, разбиением на страницы, размещением плавающих объектов (иллюстраций, таблиц), поддержание ссылочной целостности через номера страниц, и т.п.

Профессия верстальщика ужасна — тяжело, муторно, безденежно. Отлично выражается в анекдоте:

Через кладбище бредет скелет в лохмотьях. Его встречает другой скелет:

— Привет, ты тоже с ристалища?

— Ну да, верстальщик я, номер сдал, иду домой…

Всего этого нафиг на самом деле не нужно в электронном документе с непрерывной моделью верстки! И перегоняя HTML-контент через текстовый процессор, вы только выплескиваете ребенка, теряя все красивое стилевое оформление, и получая кучу проблем по бумажной верстке, бесплатно превращая себя в верстальщика.

Не делайте этого!

А что делать?

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

А если вам нужно куда-то послать эту статью, одним файлом, со всем форматированием, и картинками лучше использовать самый стандартный media-контейнер для HTML-документов:

  • MHTML, стандарт RFC 2557 еще прошлого тысячелетия (1999).

Его понимают почти все:

Вообще ситуация, что какие-то броузеры это не поддерживают «из коробки» это конечно фейл.

Так у Firefox баг на эту тему стоит аж с 1999 года, хотя есть аж два работающих расширения.

Призываю всех небезучастных пользователей FF зайти и проголосовать за этот баг! (Если знаете английский — можно добавить саркастических комментариев и т.п.).

  • Internet Explorer начиная с очень древних версий (так что «компьютерно непродвинутый потребитель» по-любому все отлично увидит).
  • MS Office — т.е. да, Word откроет и это, если заказчик, например, хочет активно порецензировать.
  • Остальные броузеры — либо открывают его сходу (Opera — проверил, Chrome — судя по википедии), либо, для пользователей FF — (небольшое увы!) нужно напрячься и поставить расширение.

Так для Firefox я пользуюсь Mozilla Archive Format, есть еще UnMHT (лично не проверял, но хвалят).

Поставив это расширение, Firefox сможет и просматривать MHT, и сохранять.

Итак, запомним, что MHTML — самый стандартный формат консервации HTMLя с картинками и стилями (да, он не оптимален с точки зрения размера и т.п., но если у вас не манга по мотивам Войны и Мира из 100500 картинок, то это все неважно).

Осталось понять, какую именно страницу сохранять в MHTML-формате, чтобы не попала всякая «навигационная обвязка».

Так вот, для этого мы сделали специальный MediaWiki-скин[1], «cleanmonobook», который берет все стилевое оформление от стандартного скина «monobook», но без навигации и всего лишнего.

У нас он вызывается ссылкой «Чистый HTML» («Clean page» для english). Используйте эту ссылку, сохраняйте и посылайте MHT-файл, если вам нужно дать кому-то на чтение и рецензирование вики-статью. (при печати оно также правильно напечатается — с подстановками URLов внешних ссылок и т.п.).

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


Удивительно, что убогая метафора документа, как «набора страниц с полями» постоянно вылезает из могилы и убивает невинных прохожих. Какой прекрасный был Google Docs, когда его только купил Google — чисто электронный документ, т.е. верстка происходит только в броузере читателя, максимум использованного пространства, отличное юзабилити. Изначально внимание гугла ограничилось кривоприкрученной, но худо бедно работающей публикацией в Blogger. И пока не трогали, все было очень даже ОК. Почти Etherpad. Но нет таки, прошло несколько лет, и Google начал развивать Google Docs, притащив туда все скелеты из шкафов — «поля», «линейки», «разбиение на страницы». Скоро принесут туда еще и MSOffic-ный ribbon. Единственное ценное — интеграцию с Blogger, они, кстати отломали и не заметили. Ну а для меня на этом Google Docs закончился.

Остался единственный, неприятный вариант. Вам нужен именно страничный, текстовый документ. Например, вы должны сдать заказчику коробку распечатанной документации в соответствии с тридцатьчетвертым ГОСТом, надо которым будет измываться отдел нормоконтроля, оставшийся с 50х годов прошлого тысячелетия.

Вот только в этом случае, вам разумно

  • заранее подготовить единую составную статью (включающую статьи-разделы),
  • перегрузить ее в текстовый процессор ссылками «→M$WORD» или «→OOffice» (раньше они у нас были «закладками», в списке действий над статьей, но сейчас мы перенесли их в список «инструментов», в стиле monobook они слева).
  • приготовится к ручной доводке документа.

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

  • С одной стороны, уверяю — это копейки, по сравнению с накладными расходами ведения документации как в ламерском стиле («много вордовых файлов»), так и в крутом («LaTeX», «SGML Docbook»).
  • C другой, как уже я сказал, — старайтесь и этого по возможности избегать. Используйте MHTML, забудьте про текстовые процессоры. YAGNI!

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

Внимание! Данная статья выбрана для репликации в SMWiki.

Статья реплицируется в Wiki4IntraNet.

2011-08-24 Bugzilla4Intranet - новые возможности

Как известно, есть у нас собственный форк багзиллы — Bugzilla4Intranet. На странице находится немного устаревшее описание, которое, кроме того, ещё и очень большое и тяжёлое для восприятия. Поэтому заметки о Bugzilla4Intranet (а также и о Mediawiki4Intranet) отныне будут время от времени появляться в этом блоге.

Конкретно сейчас я расскажу о последних изменениях в Bugzilla4Intranet:

  • Полностью переписан движок поиска (Search|Bugzilla::Search), в целях получения оптимальной производительности. Одновременно стали быстрее и view’шки — автообновляемые из сохранённых запросов поиска представления в БД для доступа к данным багзиллы извне с учётом прав. Пока что эта функция (как и некоторые другие) не документирована, но если кого-то интересует — документацию напишу мигом. Основной смысл оптимизации поиска — использование UNION вместо OR в SQL-запросах, что позволяет базе нормально использовать индексы. Также не обошлось и без рефакторинга и других доработок.
  • Убран «хардкод» URL’ов внутренних вики-систем, специфичных только для нашей компании. Теперь вместо кучи wiki_url, smwiki_url и так далее на странице «Integration» конфигурации остались только параметры wiki_url и mediawiki_urls — URL для ссылок на баги по умолчанию и таблица вик с префиксами для подсветки ссылок на вики-статьи в комментариях к багам.
  • Пронесены изменения веб-сервисов из Bugzilla 4.0.

Windows-сборка Mediawiki4Intranet

Часто бывает достаточно удобно развернуть локально Windows-сборку Mediawiki4Intranet.

Attention niels epting.svg Не используйте Шиндошс-сборку для реальных интернет-сайтов! Она редко обновляется, имеет проблемы безопасности и совместимости (например, загруженные файлы получают нестандартные имена), часть возможностей сборки недоступна, равно как и некоторые другие расширения MediaWiki, не входящие в сборку.

Да и вообще — Windows — это плохая система, которую делает плохая компания с плохой политикой. Не нужно её поддерживать.

Для Wiki, которую будет использовать более 1 человека, установите себе нормальную свободную ОС — например, Linux (рекомендуем Debian) или FreeBSD.

Последнее обновление Windows-сборки: 2015-09-04.

Зачем же нужна данная сборка, если с ней есть такие проблемы?

  • Для виндузятников это самый быстрый способ попробовать Wiki и оценить возможности Mediawiki4Intranet.
  • Можно использовать как локальную вики, развернутую на своем ноутбуке или десктопе. Можно работать в метро, самолете, пароходе и прочем лишенном интернета транспорте.
  • Можно открыть демо-вики для небольшой группы.
  • Можно поставлять такую инсталляцию заказчику, как мощнейшую систему справочной документации, которая на порядки лучше всевозможных PDF/CHM/отдельно лежащих HTML-файлов. Ибо здесь:
    • можно размещать любую мультимедиа-информацию;
    • есть система быстрого полнотекстового поиска;
    • заказчик может дополнять документацию своими страницами и дополнениями;
    • легко загружать инкрементальные обновления.
  • Почти все необходимые приложения (Inkscape, Dia, TeX, Gnuplot, Graphviz, UMLGraph, Sphinx, …) — также упакованы и приложены, система настроена на их использование.
  • Никаких конфликтов с установленными приложениями быть не должно, это portable сборка, не трогающая реестр, пути, и т. п. — самый надежный способ не упасть в DLL hell.

Чем это лучше, чем Linux-виртуалка со всем тем же самым?

  • Занимает гораздо меньше места, чем образ виртуальной машины, соответственно, быстрее ставить.
  • Не надо ставить VirtualBox, после копирования работает на любой Windows-машине, начиная с 2000.
  • Возможно, быстрее работает (но не факт!)

Скачать сборку можно здесь: http://wiki.4intra.net/public/mediawiki4intranet-win.7z

Note.svg На 64-битных виндах может потребоваться также установить Visual C++ 2008 Redistributable. Возможно, мы его включим в состав или как-то обойдём эту проблему. Но пока так.

Затем все настолько просто, что мы решили обойтись без слов, простой инфографикой:

Wiki4intranet-wampp-album.svg

→ continue reading...

2011-02-14 MediaWiki импорт-экспорт - начнём с малого

Итак, понемногу продолжим выкладывать наработки в open-source. И хотя код Bugzilla4Intranet уже «тусуется» на google code, о нём мы пока объявлять не будем, потому что в порядок описание ещё не приведено.

Пока что я хочу представить одну очень полезную доработку MediaWiki — улучшение механизма XML импорта-экспорта статей. Фичи:

  • Самое главное: поддержка импорта-экспорта загруженных файлов (изображений и т. п.) — оригинальный импорт-экспорт этого не умеет.
  • Улучшенный механизм выборки статей для экспорта — по категориям, пространствам имён, дате изменения, замыкания по ссылкам на страницы, корректного замыкания по нескольким типам ссылок.
  • Расширенный отчёт импорта и выявление «конфликтов».
  • (UPD) Также есть инструмент для выгрузки дампов из обычных MediaWiki, без поддержки сего патча.

Подробное описание и инструкции по использованию читайте здесь: MW Import&Export.

Патч доступен для версий MediaWiki 1.14, 1.16 и 1.17-dev (trunk).

2010-12-31 Поехали! ВикиПрезентации = MWSlideology в Open-source!

Итак, мы уже несколько месяцев как пообещали выложить наши интранет-разработки, о которых мы рассказывали на конференциях РИТ-2010, Software People-2010, Application Developer Days-2010, SECR-2010 и SQADays-2010 в open-source, и теперь мы приступаем к этому процессу.

Собственно очень желающим я лично в тихую раздавал готовые работающие portable WAMPP-сборки этих систем, но очень хотелось все сделать правильно, выбрать самые правильные

  • Хостинг
  • Инфраструктуру
  • Лицензию
  • Coding Standards (и вылизать код в соотвествие с ним)
  • накрыть все 150% количеством юнит-тестов и функциональных Selenium-тестов
  • написать самую хорошую документацию
  • улучшить юзабилити в соответствии с самым-самыми стандартами и идеями

… но все это параллельно с адовым количеством работы и доработок, которые мы делали постоянно, в общем, мы просто начинаем выкладывать, как есть. Документация, стандарты, тесты — все это обязательно будет тоже!

Впрочем, мы посоветовались с вами, потенциальными пользователями и сообществом — провели опрос, по поводу потенциального хостинга, и его результаты таковы:

Какой хостинг кажется вам наиболее подходящим? На данный момент распределение ответов следующее:

 Хостить на нашей площадке, с инфраструктурой Bugzilla, MediaWiki, Subver ion, SVNSearch, ViewVC   75 
 26% 
 SourceForge   67 
 23% 
 github   23 
 8% 
 Launchpad   4 
 1% 
 Freepo itory   0 
 0% 
 Google Code   46 
 16% 
 Bitbucket   9 
 3% 
 CodePlex   5 
 2% 
 a embla   3 
 1% 
 GNU Savannah   0 
 0% 
 Tigri .org   2 
 1% 
 Все равно   52 
 18% 

Заодно получился интересный опрос популярности хостингов. С удивлением мы сейчас обнаружили, что лидирует именно наша площадка (за ней Sourceforge, и третий призер — хостинг «Все равно»).

Но пару месяцев назад, когда мы как раз начали выкладывать код, лидировал именно Sourceforge. К тому же, самое ценное — это код, и выкладывание его на своем собственном хостинге, как-то не совсем отвечает духу свободы — «а вдруг они передумают?», «а если они разорятся?», «а может это PR?». Поэтому мы таки решили, самое ценное — код и инфраструктуру работы с ним — баг-репорты, фича-реквесты, положить на старый добрый SourceForge.

Да, он обвешан рекламой, это обьективно так и признается даже в «мануалах» по производству open-source:

Unfortunately, a SourceForge page also contains a great

deal of extraneous noise. The top is a banner ad, often an animated image. The left side is a vertical arrangement of links of little relevance to someone interested in the project. The right side is often another advertisement. Only the center of the page is devoted to truly project-specific material, and even that is arranged in a confusing way that often makes visitors unsure of what to click on next. См. Producing Open Source Software, стр. 67

Но все программисты к рекламе уже либо привыкли, либо отключили в своих баннерорезках.

Но вот повозившись с возможностями документирования на SF, мы поняли, что лучше наших Вик, ничего нет. Ну и опять таки принцип eat your own food привел к очевидному решению — мы решили вести документацию, новости, обсуждения на сайте сделанном на MediaWiki со всеми нашими расширениями.

Заведен отдельный независимый от нашей компании домен wiki.4intra.net. Подразумевается, что тут мы будем публиковать, описывать и обсуждать множество инструментов поддержки разработки, т.е. тулы for intranet, если понимать интранет, не только в узком смысле «десяток компов за корпоративным фаерволлом», а как «интернет для плотно связанных групп сотрудников», где упор делается на эффективность и долгострочное удобство, в противовес «интернету для всех», где что-то примитивное, хоть и highload-устойчивое, предлагается ну очень широкому контингенту.

Итак, первым будет наше изобретение, ВикиПрезентации, которые мы уже пару лет как успешно используем внутри компании. О нем можно посмотреть доклад Виталия Филиппова, «Все блюда для интранета из MediaWiki: ВикиБлоги, ВикиПрезентации, ВикиЭкзамены и ВикиЗакладки» (по ссылке видео и аудиозапись, и статья-презентация).

А код этого расширения опубликован тут: http://sourceforge.net/p/mwslideology/

Мы специально использовали DVCS Mercurial, чтобы вы могли легко делать локальные доработки и модификации, не перегружая код в отдельные системы управления версиями.

Следом за этим расширением мы выложим и множество остальных расширений и доработок MediaWiki, ну а затем уже перейдем к остальным системам.

Там местами есть сложности — как, например, публиковать нашу Bugzillу, в которой наши доработки уже занимают существенную часть кода, но при этом их нельзя выпилить и выложить в качестве отдельных расширений. Но мы думаем над этим!

Итак, пробуйте, и оставайтесь с нами — можете подписаться на этот блог, присылайте и публикуйте ваш фидбек в любом виде (комментарии, тикеты, почта).

В январе, я думаю, мы выложим все остальные Mediawikи-расширения.