Pull to refresh

Comments 16

Шёл 2015 год. Зловреды всё ещё называли вирусами.
UFO just landed and posted this here
Пользовал раньше в качестве таск-трекера и портала с инфой о текущих проектах движок DokuWiki (да и щас личный справочник пишу на нем), только потому, что его можно редактировать без браузера (ведь я известный пользователь Vim, который прикручивает его везде). Просто в один прекрасный день понял, что я не регистрирую задачи и изменения по проектам только потому, что мне лень открывать браузер, искать нужную страницу в вики и редачить ее. С тех пор только DokuWiki.
Какой-то большой оверхэд получается на фоне того же zim.
Таки нужен сетевой доступ из браузера другим сотрудникам отдела.
+ {
+ var scale = imgPreloader.height/maxheight
+ imgPreloader.height = maxheight;
+ imgPreloader.width = imgPreloader.width/scale;
+ }

Код скопирован из коммита?
Нет, этот вариант изменений в коде сделан мной для удобства при локальном использовании, в коде автора их нет.
Я про плюсики в начале строки. Это какая-то особенность скриптования для вики?
нет, по тексту, чуть ниже в спойлере, приведен полностью код для XWiki, в данном же фрагменте я не долго думая использовал особенность всех движков Вики, а именно отображение изменений на странице: сперва я вывел в страницу исходный код, а затем модифицированный и сделал сравнение версий. Плюсы означают новый контент, минусы — удаленный контент.

Что касается скриптов и API то я бы рекомендовал почитать здесь
network.xwiki.com/xwiki/bin/view/DocXE52En/ProgrammingOverview
в разделах посвященных API есть ссылки на документацию, в которой прописано что каждая команда означает.
Ищу альтернативу медиавики.

Как в xwiki с разграничением доступа? Можно для отдельных страничек в space разрешить чтение только отдельной группе пользователей? И будет ли при этом работать корректно поиск — в медиавики вроде бы все ACL-расширения костыльные — в поиске выводится все.

Есть ли возможность автоматически нумеровать статьи и в дальнейшем искать их по номеру — например, KB123456? И чтобы этот номер выводился на самой страничке. Т.е. было и номальный заголовок и номер. В медиавики такой модуль не нашел (можно сделать костылем с mod_rewrite, но поиск по номеру статьи работать не будет).

Как в xwiki с разграничением доступа? Можно для отдельных страничек в space разрешить чтение только отдельной группе пользователей?
В xwiki c правами доступа все отлично. Через админку можно создать группы пользователей, раскидать юзеров по группам и разграничить права пользователей к корневым разделам (space того же уровня что и main). Если требуется ограничить права к конкретной странице, то это делается уже на самой странице в меню Edit/Правка --> Access rights/Права доступа. Можно настроить права как для групп, так и для конкретного юзера.

И будет ли при этом работать корректно поиск — в медиавики вроде бы все ACL-расширения костыльные — в поиске выводится все.
В xwiki модуль Tags будет выдавать в т.ч. и те теги, которые находятся на скрытых для конкретного пользователя страницах, но в том же поиске — запрещенные страницы отображены не будут. Так же не находит и текст на таких запрещенных страницах.

Пару слов о поиске, а именно: т.к. русский язык не поддерживается на 100% (хотя интерфейс и переведен, нет проблем с кодировкой и отображением символов, а так же можно сделать многоязычный сайт), словоформы интегрированный поиск не распознает. Для него словоформы такие как «окно» и «окна» (склонения слов, спряжения, мн.ч. и др.) будут считаться разными словами. В то же время модуль поиска ищет текст во вложениях(включая файлы MS Office), но опять же выводит не ссылку на сам документ, а ссылку на страницу, где этот документ вложен.

Есть ли возможность автоматически нумеровать статьи и в дальнейшем искать их по номеру — например, KB123456?

На сколько я понимаю это сделать можно (поиск может осуществляться как по тегам, так и по содержимому страниц/вложенных файлов) через тот же velocity, но у меня еще не было нужды копать в этом направлении и потому готового решения предложить Вам сейчас не смогу, вот какие примеры кода на эту тему создание скриптом страниц выдал гугл (боюсь придется писать код самому под себя):
www.xwiki.org/xwiki/bin/view/FAQ/How+can+I+create+a+new+page+based+on+a+form
xwiki.475771.n2.nabble.com/Create-a-new-page-from-a-velocity-macro-td7583279.html

А это библиотека для программирования с помощью скрипта velocity
platform.xwiki.org/xwiki/bin/view/SRD/Navigation?xpage=embed
Спасибо.

Про полномочия, интеграцию с LDAP, маппингом AD-шных групп вчера прочитал и немного понял. На уровне документации все здорово выглядит.

т.к. русский язык не поддерживается на 100%

А можете еще о проблемах с русским, кроме словоформ рассказать? С ними понятно — что без нормальных внешних поисковых движков типа сфинкса или еще чего-нибудь поиск всегда будет такой. Поддерживаются ли русские названия страниц и пространств полностью? В медиавики русское название — с пробелами и прочим — можно писать прямо в адресной строке браузера (wiki.ru/wiki/Моя статья), а в примерах XWiki, что я видел, BestPractice почему-то на английском. Не придется ли авторам статей создавать дополнительные названия страниц на английском?

К сожалению, пока не на работе, испытать негде (дома м.б. попробую), а в песочнице на playground.xwiki.org я не могу править и создавать странички — не появляется кнопка правки после регистрации.
А можете еще о проблемах с русским, кроме словоформ рассказать?

Во-первых в начале этой статье я описал способы установки xwiki, самый простой из них — это скачать ZIP архив портативной установки по ссылке:
enterprise.xwiki.org/xwiki/bin/view/Main/Download
распаковать его, запустить файл start_xwiki.bat (для Windows) / start_xwiki.sh (для Linux) и не закрывать во время работы вылезшую консоль, так же излишне говорить что Java должна быть установлена на Вашем ПК. Эта сборка запускается бессчетное число раз, даже если Вы будете каждый раз перед запуском менять название каталога распакованной xwiki, и таким образом сможете попробовать функционал.

Во-вторых поддержка русского языка упирается в механизм работы со ссылками, который для русского языка создает ссылки вида:
Wiki Home\Test page\страница с пробелами
http://*Ваш_сайт*/xwiki/bin/view/Test+page/%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0+%D1%81+%D0%BF%D1%80%D0%BE%D0%B1%D0%B5%D0%BB%D0%B0%D0%BC%D0%B8
На сколько я понимаю — это Unicode, или аналог. В принципе, если не зацикливаться на том что отображается в строке ввода ссылки в браузере, сам движок предложит создать ссылку вида:
[[страница с пробелами>>doc:Test page.страница с пробелами]] — это внутренняя ссылке, хотя он переваривает и внешние вида: http://*Ваш_сайт*/*Ваш_путь*

В-третьих. Эта реализация русских ссылок упирается в базу данных. Конкретно для этой портативной сборки (в установку в контейнер я еще не пробовал) используется база HSQLDB database. Конкретно ее я тестировал путем загрузки порядка 7Гб информации в виде картинок на страницах и она обрабатывала результаты корректно. Все эти данные пишутся в один единственный файл, расположенный по пути на жестком диске: *каталог установки xwiki*\data\database\xwiki_db.lobs, однако в этой же сборке стоит ограничение на максимальный размер загружаемого файла в 32Мб, а порой требуется вложить бОльшие объемы. Тогда на помощь приходит гугл и выдает следующее решение:
comments.gmane.org/gmane.comp.web.wiki.xwiki.user/27679
Которое не работает без настройки базы данных, а именно конкретно в этой сборке где-то прошита, я еще не нашел, настройка ограничение на вложение в 32Мб, однако используя следующий костыль (Step 1: Switch to Filesystem attachments.), это ограничение обходится через настройку сохранять вложения напрямую на HDD:
extensions.xwiki.org/xwiki/bin/view/Extension/Filesystem+Attachment+Porter

Таким образом все вложения, а так же картинки меню и управляющие *.xml, будут хранится на жестком диске в соответствующих каталогах, в отличие от содержания страниц, которые будут по-прежнему хранится в БД. Здесь так же вылезает ограничение файловой таблицы на длину файла с учетом каталогов в 255символов (однако NTFS поддерживает чуть больше, но вот родной explorer, то бишь проводник, работает криво и копирование длинных путей поддерживают только сторонние утилиты, типа Total Commander'а). С учетом того, что все поддерживается напрямую через латиницу и unicode, то для языков отличных от латинской группы пути к файлам на жестком диске превращаются в такого рода:
b:\xwiki-7.1-rc-1\data\storage\xwiki\Main\%D0%9E%D0%9E%D0%9E\~this\attachments\01.jpg\01.jpg

xwiki движок обрабатывает операции с вложенными файлами с длинным названием корректно, но через ограничение длины пути файловой системы он все же переступить не может и общая длина вложений страниц на сайте упирается в этот анахронизм с 255символами (однако это лишь пути, используя поле Title можно задавать сколь угодно длинное описание страницы, которое будет везде отображаться в самой xwiki, но адресация будет вестись к конкретному короткому названию в путях). К сожалению этот костыль порождает одну единственную проблему — при удалении вложенного файла обрабатываются корректно лишь записи в БД о нем, но физически файл не удаляется с жесткого диска, а так же не отображается в корзине удаленных файлов в xwiki, в отличие от удаленных страниц, которые до удаления из корзины восстановить все же можно (но уже без вложений). Напротив, если принять ограничения в 32Мб на аттач и пользоваться сохранением всей информации, включая вложения, только в БД, то все работает как часы (включая отображение удаленных вложенных-файлов в корзине)

Отсюда мини-вывод: если необходимая корректная работа на 100% нужно работать через БД.
либо мириться с прогнозируемыми неувязками…
сегодня постестил немного портативную версию. очень понравилось.
советую обратить внимание на аддоны, которые доступны для скачивания как через сайт:
extensions.xwiki.org/xwiki/bin/view/Main/WebHome
Так и через админку EXTENSION MANAGER пункт Add Extensions.

Меня приятно порадовал на днях следующий аддон:
extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Application
Который позволяет уже заняться структуризацией своих задач и работы :)
Sign up to leave a comment.

Articles