wiki движок для отдельской базы знаний

Имхо, WYSIWYG — зло. Пусть учат разметку.

Возможность перенести малой кровью на другие движки — маловероятно, в основном у каждого движка wiki свой свой синтаксис разметки.

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

Я настраивал dokuwiki на небольшую команду. По пунктам:

1. Да, опенсорс
2. Ну, как бы да
3. Да, наверняка, но я запускал в докере; с переносом на другие движки хз, наверное сложно
4. Визуальный редактор нужно плагином ставить, он сорт оф работает (насколько знаю, в mediawiki визуальный редактор как на википедии запиливать боль, надеюсь на самом деле это не так)
5. Не понял, что такое система хранения литературы? Можно загружать файлы, есть менеджер загрузок, плагином вроде можно автоматически спискоту генерировать
6. Вообще хз, Jupyter это какая-то инопланетная технология для меня
7. Подсветка есть для широкого набора языков
8. Кажется, было такое плагином, но не уверен
9. Я докером запускал, минут 10 и готово
10. Права на чтение/запись в наличии – немного странная система, но не слишком, можно разграничивать по разделам и по страницам

Про WYSIWYG – присоединяюсь, что писунам лучше заботать разметку тоже. Даже если пишешь в какую-нибудь ынтерпрайзную конфлюенцу, знание разметки очень помогает сделать удобно и красиво.

mediawiki

работает на php

C WYSIWYG дилемма в том, что хочется приобщить к наполнению вики и читателей, и максимально снизить порог входа.

У dokuwiki только 2 минуса: php и не markdown.

Как и докувики.

Маркдаун сильно ограниченный.

5.Не понял, что такое система хранения литературы? Можно загружать файлы, есть менеджер загрузок, плагином вроде можно автоматически спискоту генерировать Сейчас наши книжки и статейки лежат по папкам на сетевом диске, хочется для них организовать хранилище на базе вики движка. Эдакую электронную библиотеку. Но похоже я что-то перемудрил и это лучше делать не вики движком.

Всё равно не совсем понятно, как будет выглядеть. Я бы поднял nextcloud, если так хочется. Там вроде есть теги для более удобной организации.

docuwiki тоже может работать с sqlite вместо мускуля?

Готова к работе из коробки (не требующая ковыряния php, js, итд.).

mediawiki все таки требует ковыряния localsettings.php но вся информация есть.

ikiwiki, лишнее отсекаешь.

Jupyter

Проклято.

она и вообще без субд работает

У докувики вообще база данных на текстовиках, там нет ни мускуля, ни скулайта.

что это за фигня тогда?

я слышал мельком да это жесть неполный функционал.

В общем как я понимаю mediawiki и dokuwiki наиболее подходят под озвученные требования, вопрос только какую из них выбрать?

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

~50 чтецов и 2-3 человека редакторов

докувики, всем пунктам соответствует, возни меньше.

Кроме, наверное

WYSIWYG редактор;

Там визивиг полуавтоматом (редактор+пред. просмотр). Плагином наверняка можно полный визивиг воткнуть; а вообще баловство это.

Недавно открыл для себя XWiki.

Функциональность расширяется плагинами. Среди плагинов, например, поддержка синтаксисов MarkDown и MediaWiki.

Под капотом крутится OpenOffice (для импорта из офисных форматов) и Solr (для полнотекстового поиска).

1. Бесплатна для коммерческого использования;
2. Достаточно широкое комьюнити, чтобы не оставаться с проблемой один на один;
3. Работает на Linux. Про возможность перенести на другие движки - это вряд ли, но это относится, я думаю, к любому движку;
4. Интерфейс не как в Wikipedia, скорее Confluence, WYSIWYG редактор в наличии;
5. Файло можно пристёгивать к статьям и можно на них ссылаться в статьях - по клику будет скачиваться или показываться в зависимости от типа файла.;
6. Jupyter не знаю;
7. Подсветка синтаксиса есть (плагином);
8. LaTeX вроде видел в плагинах, но это не точно;
9. Java. Пускаю в докере.

Права на статьи и разделы раздаются.

Плагины тут: https://extensions.xwiki.org/xwiki/bin/view/Main/WebHome

Плагин легко гуглится, сам не проверял его, не могу утверждать.

Так юзеры ещё. UPD. Посмотрел сценарий деплоя, который пилил для переноса докувики в контейнер, не вижу там бд.

В файле.

а где будут храниться аккаунты пользователей например? всегда же в бд.

Всё равно не совсем понятно, как будет выглядеть. Я бы поднял nextcloud, если так хочется. Там вроде есть теги для более удобной организации.

Я это представлял как на каждую книгу/статью будет выделена шаблонная страница с тегами. К странице будет прилинкован непосредственно файл. И всё это будет загружаться/создаваться при помощи какого-нибудь расширения или базовыми функциями вики-движка.

P.S. Это v_0ver, просто пароль от ака пролюбил.

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

Пусть учат разметку.

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

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

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

Тогда не знаю. Никогда настройкой подобных штук не занимался. Мне кажется, что просто файлохранилище с тегами (и адекватными именами файлов, а не 678132648172638.pdf) будет проще и надежнее.

P.S. Это v_0ver, просто пароль от ака пролюбил.

Юзай парольные менеджеры, ну (keepassxc или что-то другое по вкусу).

Маркдаун прикручивается плагином. PHP минус, только если контрибутить собираешься, иначе вообще плевать: рукожопов полно и на пыхе, и на питоне.