Вопросы по установке Mediawiki4Intranet
При установке в свою систему (Gentoo линукс) сборки Mediawiki4Intranet, взятой здесь, возникло несколько проблем, которые без посторонней помощи не удаётся решить.
Ошибка отображения иконок в меню, относящихся к IntraACL
Первая проблема заключается в следующем, что при редактировании страницы в меню не отображаются картинки относящиеся к IntraACL, как показано на рисунке.
Я конечно ничего в этом не понимаю, но в исходном коде страницы видно, что переменные php (например, $haclgHaloScriptPath) по какой-то причине не заменились на свои значения:
<form id="editform" name="editform" method="post" action="/wiki4intranet/index.php?title= %D0%97%D0%B0%D0%B3%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D1%81%D1%82%D1%80%D0%B0%D0%BD %D0%B8%D1%86%D0%B0&action=submit" enctype="multipart/form-data"><div id="hacl_toolbar"> <?= wfMsg('hacl_toolbar_no_right_templates', $quick_acl_link) ?> <a style="text-decoration: none" class="haclt_title" target="_blank" href="index.php? title=Special:IntraACL&action=acl&sd=<?= urlencode($haclgContLang->getPetPrefix(HACLLanguage::PET_PAGE).'/'. $title) ?>"><img src="<?= $haclgHaloScriptPath ?>/skins/images/edit.png" width="16" height="16" alt="Edit" /> <?= wfMsg('hacl_toolbar_advanced_'.($pageSDId ? 'edit' : 'create')) ?></a> <div class="qacl"><a target="_blank" href="<?= $quick_acl_link ?>" title="<?= wfMsg('hacl_toolbar_qacl_title') ? >"><?= wfMsg('hacl_toolbar_qacl') ?></a></div>
Думаю, что не хватает какого пакета, но какого идентифицировать не могу. Возможно это связано со следующей проблемой?
Ошибка на странице
На заглавной странице (и на некоторых других) вверху страницы выдаётся следующее сообщение:
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method MarkupBabel::AutoHighlight() should not be called statically in /var/www/localhost/htdocs/wiki4intranet/includes/Hooks.php on line 133
Пробую устанавливать Mediawiki4Intranet дома (свежая система) и на работе (год без обновления). Проблема с картинками IntraACL наблюдается на двух системах, а приведённое выше сообщение об ошибке выдаётся только на домашней системе.
[ List view ]Comments
Николай, это сборка для Windows, для WAMP, громоздить ее на Linux наверно неправильно, хотя возможно даже что-то и взлетит... Вы ищите наиболее простой способ установить все это под Linux? Или я что-то не понял?
Я ставлю под линукс Mediawiki4Intranet из архива исходников, ссылка на который размещёна на странице Mediawiki4Intranet. Т.е. речь идёт не про виндовс сборку. Просто Gentoo устанавливает пакетов по минимуму и возможно, что для правильной работы Mediawiki4Intranet нужны дополнительные пакеты (которые не описаны на основной странице), которые не нужны для стандартного движка Mediawiki. А возможно нужны какие-то настройки php или ещё что...
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 к старой базе вылезло много мелких отличий в синтаксисе. Например:
При этом есть исключение:
и получалась таблица, в которой "two" печаталось абзацем в рамке с моноширинным текстом, а в wiki4intranet получаем так
Первый уровень[edit]
Второй уровень более жирный[edit]
Это скорее не первый и второй, а второй и третий уровни. Ну да, у нас третий сделан жирным шрифтом. Он меньше, но жирный, чтобы выделялся. Это произрастает из extensions/CustisScripts/custis.css. Можно там и изменить.
Проблему с кодировкой не наблюдал. А это у вас Windows-сборка или Linux, какая ОС и какой браузер? И, кстати, попробуйте отключить WikEd (такой мелкий карандашик кликнуть в правом верхнем углу страницы, около логина). Если уйдёт — значит какие-то проблемы WikEd’а.
С пробелом… Да, есть такой момент. Это наш патч к парсеру, на doBlockLevels так работает)) зачем сделали патч — чтобы поправить следующие несколько багов:
И как бы понятно, что без изменений парсинга тут не обойдёшься. В итоге есть ещё два отличия:
С пробелом в начале строки — там не после абзаца, а после элемента списка глючит только. Посмотрю, может можно поправить. Но что характерно, все тесты парсера оно проходит :) видимо на это там тестов нет :)
Спасибо за развернутый ответ, но к сожалению я мало что понял касательно тонкостей парсинга...
По поводу уровней, заметил что в разных браузерах отображаются по разному (в моей старой опере ещё терпимо), а вот Firefox показывает так:
Тут не совсем заметно, что шрифт более мелкий на третьем уровне...
По поводу проблем с кодировкой соберу больше фактов... Вообще вопросы касались линукс сборки, но оперу юзали из виндовса.
Да, действительно не очень заметно. :) ещё зависит от установленного шрифта по умолчанию. Там действительно небольшая разница, 150% и 140%. Может и надо что-то с этим сделать, не знаю. Подумаем.
А как получить в Mediawiki4Intranet такой вот результат.
Как исправить исходный текст, чтобы получить тот же результат как в mediawiki?
Если вам нужно именно "слабое преформатирование", то есть <pre>, в котором можно использовать разметку - то в данный момент внутри таблицы никак. Если просто фрагмент кода - написать <pre>код</pre.
Если так сильно нужно - можно патч откатить нафиг.
Есть у меня такой Шаблон:Hider
Он делает свёрнутый список. К нему в нагрузку нужно дописывать текст в common.js.
Этот шаблон вставляет такой html-текст
Но с переходом на Mediawiki4Intranet такой список становится по умолчанию всегда открытый. Закрыть его можно только нажатием кнопки "Закрыть". При этом он закрывается, но надписи накладываются как показано на рисунке.
В чем тут может быть проблема? Почему списки стали развёрнутыми по умолчанию, и почему не прячется "Показать"? Можно это как-то поправить?
Какой код у шаблона Anchor?
Такой
Хи-хи, треш))
TestHider
Всё нормально работает...
Я это видел, что тут работает. Но тоже с особенностями, кнопка Скрыть/Показать внизу, а не справа... А какие-нибудь мысли почему у меня отвалилось это дело есть? Ладно, буду пробовать танцы с бубном.., попробую почистить common.js/сss, ...
А, точно. Да не, чего там чистить. С тем что справа как раз всё понятно — если убрать пробелы из начала строк и перевод строки после <div>, всё нормально становится.
Это как раз одно из того чего фиксили:
Смотри, я поправил.
А почему у тебя отвалилось - скопируй сюда код, на котором отвалилось, и посмотрим.
Ну я и говорю - скопируй сюда код, который отвалился, и посмотрим.
Код такой например
у меня развёрнут при просмотре на моей Mediawiki4Intranet
Хм. Странно, сам по себе действительно не отваливается. Нужно смотреть что там ещё есть в этой статье... Что-то там не слава богу.
Собственно говоря, часть, ответственная за дивы, в нашей сборке мало отличается. Так что вряд ли проблемы с Common.css и Common.js.
Выкинул содержание MediaWiki:Common.js, заработал Hider. Common.css оставил, чтобы рамку рисовал вокруг списка.
А, ё-моё, у тебя свой Common.js был прописан... У нас-то он в комплекте поставки в CustisScripts...
Заметил, что файлик skins\custis.php имеет перевод строки как в виндовс (0D 0A), сильно бросается в глаза... Конечно не критично, и наверно, не повлияет ни на что...
Ага, ни на что не влияет, но для порядка поправил.
В mediawiki для формул используется тег <math>, а в Wiki4intranet просто <m>, причем стандартный тег по умолчанию отключен. Получилось при подключении старой базы к новому движку отвалились все формулы... Как предлагаете решать эту проблему?
Завтра буду пробовать, что получится из этих вариантов...
По предложенным путям решения:
1. у меня это заработало. Я под линуксом это дело подымаю, в старой вики texvc был, я его и заюзал. Но с <m> не помогло, см. ниже коммент.
Проги dvisvgm у меня не стояло...
Остальное ещё смотрю...
Ну да, если texvc уже был, то логично. Я к тому, что так бы тех под виндовой сборкой не работал, а он у нас там нужен...
Нет, дописал, но он включается, только когда $wgUseTex = false, чтобы не конфликтовать со стандартным мэтодом.
Виноват, не досмотрел.. Верней смотрел, но не туда... Всё работает, спасибо.
Что-то мне везёт... Всё началось с исчезновения 10ГБ места, что привело к вешанию mysql. Поиск виновника привел к файлу
После его удаления я не долго радовался свободному месту на диске, так как в скором времени этот файл снова вырос. Оказалось, что при использовании на странице тега для вставки формулы, например, <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ГБ ошибок направить...))
Ну зато мыскль не сдохнет :)
Вот ещё сообщение из лога, почему-то в корень лезет за иконкой
Путь в BaseSettings.php задан не существующий файл.
А $wgFavicon=/favicon.ico задано в настройках по умолчанию, но проблема, что если я меняю путь $wgFavicon к существующему файлу, то проблема не решается...
И ещё непонятная штука вылезает
Не работает под PHP 5.2.8 на OpenSUSE 10.2. Валит ошибки на функционал, появившийся в PHP 5.3. Например:
Хм. Спасибо за замечания. Поправим.
Поправил, обновил сборку. На заметку: маркированные списки в mediawiki делаются с помощью * в начале строки :-)
А как PHP 5.2.8 - заработала сборка? :)
да, спасибо.
Так себя должны вести картинки в разных форматах? В PNG формате вставляться, центрируясь по вертикали, а в SVG формате вставляются как буквы, лежат на строке.
Да... Сам тоже замечал, но почему-то не исправлял. Не знаю, почему, vertical-align: middle на них отлично работает, щас проверил :-)) поправлю))
(Разница в том, что у нас SVG вставляется как SVG, а не растеризуется, как в обычной вики)
Надеюсь я ещё не сильно вам надоел со своими вопросами... Вот ещё одну особенность обнаружил. Если загрузить картинку SVG в вики, а затем добавить новую версию этого рисунка, но уже в формате PNG, то похоже система воспринимает новый png-рисунок за svg-текст... Вот пример , у меня эта страница выглядит так:
Зачем надоел, мы тут наоборот радуемся, что нас тестируют :-)
А в смысле - загрузить новую версию того же файла, но PNG - это как вообще? Ты в качестве svg png'шку загружаешь (и под именем .svg)? А чего ты ждёшь от вики в таком случае? :-)
А почему нельзя загрузить новую версию рисунка в другом формате? У меня, честно говоря, и мысли не было, что так делать не правильно... И предупреждений вроде не вылазило никаких... Ладно, теперь буду учитывать на будущее...
Ну не знаю, вообще-то это логично, что "File.svg" это SVG, а не PNG.
Единственное, к чему здесь есть претензия - то, что вика не выругалась. Обычно она вообще-то ругается, говорит что тип файла не соответствует расширению. А тут что-то не стала - нужно это проверить.
Проверил - у нас была отключена проверка MIME-типов при загрузке файла из-за того, что какое-то время назад (возможно, даже ещё в 1.13 - 1.14) совсем неправильно определялся тип Visio-документа как Word'овского, и соответственно не получалось его загрузить под расширением .vsd вообще.
Сейчас уже стало лучше (определяется как vnd.ms-office), поэтому запатчил файл с сопоставлением расширений MIME типам, и включил проверку обратно. Теперь PNG поверх SVG загрузить не даст :) сейчас только сборку ещё обновлю.
удалите ответ. не нашел как
Плохо выглядят формулки внутри текста. Хотелось бы отрегулировать размер (сделать меньше) и что-то с центрированием по вертикали картинки формулы сделать, чтобы когда есть нижний индекс немного опустить картинку, если это возможно, конечно...
Насчёт меньше - не будем точно, т.к. при установленном в браузере увеличенном шрифте будет вообще мизерно. Сейчас по-моему вполне соответствует стандартному.
Насчёт вертикального выравнивания - да, разумное замечание. Постараюсь исправить.
"Насчёт меньше - не будем точно" - хотя бы скажите, где это можно поправить?
Я даже сходу и не скажу. Это нужно чтобы тех больше картинку делал на выходе. А кинь скриншот, что тебя так сильно расстраивает, что ты их уменьшить хочешь?
выглядит так
Слишком крупные формулы внутри абзаца получаются... Большие интервалы между строк получаются и абзацы уже смотрятся не так...
Центрирование тоже смотрится не очень, тут нужно различать:
В каждом случае будет базовая линия на разной высоте, поэтому нужно как-то по-другому эту проблему решать (не центрированием). На всякий случай, у меня это выглядит так:
Может параметр ввести в <m> для задания смещения по вертикали, или html-разметка такое не позволяет делать?
Да это-то понятно. Просто где её взять-то, базовую линию. Мне вот интересно, как то же самое в оригинале mediawiki рендерит?
На википедии выглядит так
У них простые индексы в формулах кодируются простой html-разметкой, а формулы вставляются центрируясь по вертикале.
Ну, простые индексы-то понятно, их всегда так можно написать. Вертикальный отступ задавать можно, но руками это делать - по-моему грустное занятие будет... Вот если бы найти способ узнать положение baseline в результирующей svg'шке...
Наверно можно Latex попросить, чтобы выдал baseline каким-либо образом..
Добавил предложение/просьбу на этой страничке Блог:TechTools/Предложения по расширению возможностей Mediawiki4Intranet.
Please login to comment.