All Wikilog Comments

From Wiki4Intranet
Jump to: navigation, search

[ List view ]Comments

  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

Congratulations and thank you for keeping ACL live.

Linux Install: I successfully installed Mediawiki 1.21.15 the normal way, extracted the Mediawiki4Intranet.zip html directory and updated LocalSettings and BaseSettings to have a look see.

wiki.4intra.net/Special:Version refers to 1.26.2.

Can one install 1.26 and if so how?

Sorry, I've missed your comment.

Now you can install 1.26 from github, from the master branch.

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

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

Второе - уже на второй машине, где я пытаюсь поставить 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, если он там есть...

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

С разморозкой меня, решил ответить на этот пост.

Первое, в принципе, реально - полученную pdf'ку можно обрабатывать inkscape'ом. Но переходить на это не будем точно, картинки не совсем красивые получаются и медленнее конверсия. Плюс ещё момент - у нас сейчас, насколько я понимаю, оно вообще не даёт свои пакеты подключить в заголовок.

По поводу второго подозреваю, что лучше ничего нет, плюс лично мне и не приходит в голову, как это сделать лучше.

Попался мне такой вот граф, полученный в Graphviz. Попробовал я его в вики, но он получился немного другим. В исходном связи проводятся ортогонально, как я понял это задаётся при вызове dot с помощью ключика -Gsplines=ortho. А нельзя ли сделать управление ортоганальностью линий доступным из вики, чтобы повторить этот граф?

[svg]

Что-то я посражался с этой опцией splines=ortho, но ничего не вышло... Связи как были дугой так и остались, добиться ортогональности не получилось...

Есть ли возможность писать звук с микрофона или аудиосистемы ПК?

Моежет подскажите, как вставить на страницу видео файл (flv), доступный по http, не загружая его в вики, как картинку?

Получилось как-то так:

<html>
<object  width="640" height="480">
     <param name="movie" value="/mediawiki4intranet/extensions/FlvHandler/flowplayer/flowplayer-3.1.3.swf" />
     <param name="allowfullscreen" value="true" />
     <embed type="application/x-shockwave-flash"
            width="640" height="480"
           allowfullscreen="true"
           src="/mediawiki4intranet/extensions/FlvHandler/flowplayer/flowplayer-3.1.3.swf"
           flashvars='config={"playlist":[ {"url":"http://localhost/files/lolo.flv","autoPlay":false,"fadeInSpeed":0} ] }' />
</object>
</html>

Только картинки начальной нет...

Чтобы картинку генерить, надо загружать видео в вики.

Если она уже есть сгенерированная, можно прописать её в playlist как-то так:

config={"playlist":[ {"url":"<картинка>", "autoPlay":true}, {"url":"<видео>","autoPlay":false,"fadeInSpeed":0} ] }

А что значит это сообщение?

Comment-note.png

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

Наверное, это баг :-) нужно расследовать.

Что делать с такой особенностью? При создании слайдов в режиме просмотра страницы VHDL-код с подсветкой синтаксиса светится отлично, а в режиме слайдов — подсветка пропадает, и код выглядит очень уныло... Вот пример Проверял в Opere и в Firefox.

Можно ли как-то такое победить?

Там у нас два расширения вкручено для подсветки кода - одно стандартное, другое наше. Стандартное включает стили в <head> страницы, наше включает все стили как inline (<span style="">) - несколько увеличивает объём кода, но зато не требует подключения отдельного сгенерённого CSS, который как раз и не попадал в код страницы в режиме презентации.

Но фиксится это легко, так что уже пофиксил. Обновляй экстенжн S5SlideShow (например отсюда). Ну либо всю сборку, там ещё пара доработок появилась в последнее время, например поддержка Tika для индексации содержимого файлов (типа вордовских и прочих), и Lightbox'ы :)

Обновил. По ходу наткнулся ещё на одну проблему. Захотел небольшой flv-загрузить и вставить на страницу, но он вставляется просто ссылкой на страницу с файлом, а не как видео. В чем проблема может быть? Посмотрел расширение FlvHandler, обнаружил там строчку $wgFlowPlayer = 'extensions/FlvHandler/flowplayer/flowplayer-3.0.3.swf';, Хотя у меня в flowplayer файл flowplayer-3.1.3.swf (аа, он потом в BaseSettings.php ставится правильным...). Но это исправление у меня ни на что не повлияло.

С путём там всё нормально было, хотя и прописан он был не совсем где надо (уже поправил) - в BaseSettings.php, а не в файле расширения.

В чём проблема может быть...

А вот если открыть страницу самого файла - его тип там вообще определяется? Должно быть написано "Файл (Video, X × Y пикселей, размер файла: Z МБ)"

Написано так:

Скрин_каст_по_работе_с_QuestaSim.flv‎ (размер файла: 675 КБ, MIME-тип: video/x-ms-asf)

Ну так video/x-ms-asf - это не FLV и не MP4... Оно не поддерживается)

Понял. Буду исправять...

... Знать бы ещё как перекодировать в flv...

Обнаружилась проблема с ParserFunctions, если правильно понял. Следующая строчка

{{ #expr: {{#time: z | 15 Marz 2013 }} - {{#time: z}} }}

не работает. Выдаёт ошибку

Fatal error: Class 'MWTimestamp' not found in /vol/md0/sites/mw4i/extensions/ParserFunctions/ParserFunctions_body.php on line 417

Но в старой сборке вики 1.16.2 и ParserFunctions (Версия 1.3.0) всё было Ок. Как быть?

Это новая версия ParserFunctions использует класс, которого в 1.18 нет.

Исправил (бэкпорт сделал). Обновитесь с помощью repo.php, должно всё стать хорошо. Либо чуть позже из архива.

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

А где эта настроечка, что-то я не нашел её сходу. А я отслеживаю изменения через RSS по свежим правкам, но мешают сообщения о новых юзерах, их каждый день до 10 штук регится, и судя по именам - 99% из них похоже боты какие-то...

Ага, боты и есть. Нашёл бы я авторов XRumer-а - ноги бы вырвал.

Настройка в пользовательских настройках, которые в углу справа сверху, на вкладке "другие настройки".

Это, правда, подписка именно на комменты.

Please login to comment.