Comments - Блог:TechTools/Вопросы по установке Mediawiki4Intranet

From Wiki4Intranet
Jump to: navigation, search

[ List view ]Comments

Николай, это сборка для 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

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

Какой код у шаблона Anchor?

Такой

<!--
 -->{{#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>

Хи-хи, треш))

TestHider

Всё нормально работает...

Я это видел, что тут работает. Но тоже с особенностями, кнопка Скрыть/Показать внизу, а не справа... А какие-нибудь мысли почему у меня отвалилось это дело есть? Ладно, буду пробовать танцы с бубном.., попробую почистить 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 делаются с помощью * в начале строки :-)

А как PHP 5.2.8 - заработала сборка? :)

да, спасибо.

Так себя должны вести картинки в разных форматах? В 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 каким-либо образом..

Please login to comment.