Какой движок выбрать для простой «вики» со статьями?

Сначала ты выбираешь дерево а потом не знаешь к какой ветке отнести статью. Не надо так.

Что значит «неубираемых с глагны функций»? Левая панель? Со временем ты всем будешь пользоваться. Кстати, у медиавики есть темы.

Список статей… У тебя их десяток будет? Нужны ссылки со статьи на статью и проставленные категории. Ты думаешь бумажными листами. Начни думать знаниями.

Мне вики в trac очень нравится, но не знаю можно ли там полностью выпилить функционал VCS

Список статей… У тебя их десяток будет? Нужны ссылки со статьи на статью и проставленные категории. Ты думаешь бумажными листами. Начни думать знаниями.

Да нет, конечно, не десяток. Что значит «думать знаниями»? Я виду это именно как «листы», да.

Фиксированный текст это дамп. Даже если не использовать каких либо особенных приёмов (что там у них, «семантические вики», не знаю), то даже категоризация даёт совершенно другой подход к текстам. А ещё можно, например, включать одну статью в другую (или включать фрагмент).

Пачка листов не имеет смысла. Листы должны складываться в ту последовательность, что нужна тебе здесь и сейчас. Структура.

lionwiki

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

Что тогда ты советуешь? MediaWiki?

Представь, что у тебя 1000 статей - как ты будешь по этому дереву ползать(то что слева)?

Что я пропустил? Что еще можно потыкать?

Тебе не нужна вики, тебе нужен бложик.

Git-реп, статический генератор страниц из markdown/rst/..

Вариантов куча, разнообразных тем к ним тоже.

Представь, что у тебя 1000 статей - как ты будешь по этому дереву ползать(то что слева)?

Ну и как тогда вообще по контенту ориентироваться?

Что я пропустил?

Fossil предоставляет вики-движок.

Тебе не нужна вики, тебе нужен бложик.

Вон там выше вещают про концептуальные переплетения статей…

Бложик можно и на вордпрессе собрать, но он как-то так себе получается по юзабелности, на мой взгляд.

тэги, полнотекстовый поиск …
Не? а ля локальный гуголь

Не? а ля локальный гуголь

Ну фиг знает.

Вон там выше вещают про концептуальные переплетения статей…

Статические генераторы поддерживают теги и поисковые виджеты. Так что «переплетающиеся» статьи можно маркировать общим тегом, и по ним можно искать.

И теги работают лучше чем иерархия.

Тут скорее вопрос в том кто будет писать. Если один человек - то git со статикой проще всего.

Если ты хочешь платформу для редактирования людьми не знающими Git - то тогда нужна вики, но и админить её намного сложнее.

Тут скорее вопрос в том кто будет писать. Если один человек - то git со статикой проще всего.

Да, один человек. Насчет гита - как это на хостинг прикрутить без VDS? Никак, получается.

как это на хостинг прикрутить без VDS?

git надо не на хостинг, а на github/gitlab/bitbucket и т.п.

Сейчас вроде все разрешают приватные репы делать.

И потом настроить Gitlab CI или GitHub Actions, которые на merge генерят сайт и заливают его на FTP или что там у тебя есть для хостинга.

И потом настроить Gitlab CI или GitHub Actions, которые на merge генерят сайт и заливают его на FTP или что там у тебя есть для хостинга.

Что-то это похоже на удаление гланд через одно место. Зачем вводить лишнюю сущность в виде гитхаба?

Она походу не знает что генераторы статики можно совсем без гита юзать.

Да, медиавики это хороший выбор.

Если у тебя есть некая вещь или инструмент, или скажем некое знание, но когда это надо ты не можешь найти, то у тебя нет этого. Знания должны быть правильно организованы.

У тебя есть некий корпус знаний, который ты хочешь поместить в некое хранилище. Важно чтобы произвольный человек мог в два-три клика найти нужное описание. Да, ты сам через несколько месяцев после написания становишься произвольным человеком.

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

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

https://wiki.js.org/

Все статьи хранятся в виде .md файлов

Пользую mkdocs, можно генерить странички локально и заливать готовую html/css/js требуху куда надо. Правда у меня страниц не так много и я ими прицельно кидаюсь в нуждающихся, с поиском особо не разбирался.

Слева древовидная структура категорий и статей, справа тело статей. Все просто.

https://textpattern.com/

Tiki Wiki CMS еще глянь

TiddlyWiki

лёгкость
простота
Слева справа древовидная структура категорий и статей, справа слева тело статей … на главной можно «Последние» показывать.

P.S. Node.js ; каких 70 МБ памяти на сервере займёт

Ну и на BookStack до кучи посмотри https://www.bookstackapp.com/

Зачем вводить лишнюю сущность в виде гитхаба?

Пишешь/правишь статью, делаешь commit, делаешь push — и твой бложик автоматически обновляется. Профит.

Про плюсы VCS как таковых давай не буду рассказывать, ладно? %)

Что еще можно потыкать?

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

Можно самому написать за вечер, если внешний вид и безопасность не имеют большого значения.

Да, тоже приходили такие мысли. Я их даже записал - мб потом возьмусь. Но сейчас пока времени нет…

потому что вики - это также система коллективных правок.

потому что вики - это также система коллективных правок.

Да. Но мне это не нужно =)

DokuWiki - идеал, но на хостинге не работает из-за связки nginx+apach. Первый отдает txt файлы со статьями напрямую в обход апача, наплевав на его всякие там .htacess и прочее.

Если вы про возможность на прямую обратиться к data-каталогу dokuwiki, то просто вынесите его за пределы web-директории. Обычно хостинги это позволяют. Всегда выношу conf и data за пределы веб-сервера.

bookstackapp

Любую вики, которая заведется на твоем быдлохостинге. Потыкаешь, начнешь понимать, что тебе конкретно надо, а не «чота на первый взгляд не нравится» /тхреад

DokuWiki - идеал, но на хостинге не работает из-за связки nginx+apach

Нет, ты уж настрой нормальный прокси пасс.

Хм… Ведь это идея. Доступ к нему у скриптов при этом будет, а вот апач его отдать не сможет.

А путь к нему там где-то в конфиге просто прописан?

Нет, ты уж настрой нормальный прокси пасс.

У меня нет доступа к конфигам.

Пиши в саппорт.

Пиши в саппорт.

Ты первый пост-то читал? Проблема с докувики на этом хостинге возникла не только у меня, саппорт разводит руками и «ничего поделать не может». На хабре даже была про это статья. Собственно, оттуда я и понял, где собака порылась - до этого полдня пытался настроить права.

Беда...

Зато у апача есть .htaccess

Беда…

Именно. Я очень разочаровался, если честно. Но менять хостинг, на котором уже вертятся два сайта, и который проплачен на год вперед, как-то не Ъ.

Зато у апача есть .htaccess

Нгинкс отдает файл раньше, чем апач разбирается со своими хтаксессами.

https://qna.habr.com/q/545490

Это значит так настроен нжинкс. И видимо они неренастроить не могут. А вот почему не могут — не понятно без подробностей которые нам не расскажут. Короче ребятки жидко обосрамс.

Там выше ссылка с цитатой ответа саппорта. Но таки да, печалька.

Хотя мне там вот выше дельный совет дали про выност директории с датой за пределы веб-директории. Надо попробовать будет.

попробуй jekyll

Nginx не найдёт и будет 404. Не парься, не экономь, возьми медиавики, если через год не забросишь и объём будет расти то не пожалеешь. А для двух десятков статей, да, можно и просто файлы, вот некстклауд поставь и в нём держи, бонусом кучу всего получишь. У него каталог с данными в описании рекомендуют сразу выносить а прямых ссылок там нет, nginx побочных эффектов не даст.

возьми медиавики, если через год не забросишь и объём будет расти то не пожалеешь

Возможно, что потыкаю ее еще раз, да. Спасибо за советы.

А в ней можно спрятать функционал «вики» от мимокрокодилов? Мне нужно, чтобы править и писать статьи мог только один человек (админ), и чтобы в анонимусов, забредающих на этот викиблог, не было видно всяких там ссылок сюда, свежих правок и прочих онливиковых штук.

Поковырял вордпресс и накидал на нем - но там даже при условии адекватных рубрик и «архивов» как-то все немного не то, мне кажется.

Или я слишком загоняюсь, хочу странного, и надо просто забить болт и не делать себе и другим мозг, взяв пресс и сделав просто очередной бложик?

Да, редактирование запретить конечно можно (вместо «редактировать» будет «смотреть исходник»). Не знаю можно ли запретить смотерть историю и технические данные, но если тебя беспокоит не утечка а просто не хочешь пугать посетителя, то на википедии-то это никого не пугает. А её все видели, все привыкли, наоборот, хорошо знакомый интерфейс.

Можно также сделать материал недоступным без авторизации (внутренняя документация). Для разделения материала чтобы часть статей видно а часть нет – если не ошибаюсь возможности нет.

Вордпресс, насколько я его видел, плохо подходит для структурированной информации. Но смущает твоё «викиблог». Если тебе всё же именно блог то движок вики пожалуй плохо подходит.

Но смущает твоё «викиблог». Если тебе всё же именно блог то движок вики пожалуй плохо подходит.

Здесь, наверное, проблема в том, что я пока сам не могу четко описать, как я это вижу. Просто появилась мысль сделать эдакую электронную записную книжку, куда записывать какие-то свои мысли или найденную в процессе работы полезную информацию. Блог - обычно это просто статьи друг за другом, где со структуризацией так себе. Вики - что-то более близкое, но… Все равно что-то смущает =) Сформулировать, что конкретно, я не могу.

Ощущения:

• Блог - куча статей подряд, найти что-то там при необходимости сложно.
• Вики - с поиском более круто, но нет структуризации как на блоге (чтоб интересно было читать подряд), эдакая куча связанных друг с другом статей (поправь, если неправ).