CMS Grav — Markdown в плоских файлах

Очень любопытно. НО! Как там с поиском если нет базы. Далее есть проблема - сайты создаются для клиента. Клиент часто с компьютером совсем ни дум дум. А тут маркдаун.

Собственно я тут тоже свою CMS наверное буду писать. В качестве БД планирую использовать монгу. Все является объектом которые сериализуются и поднимаются из монги. Пути (как и разные меню) это структура в монге в которой будут ID объектов. Каждый объект может быть (а может и не быть) контейнером (например страница это контейнер для текстового блока и картинки.

Все объекты на странице помещаются в плейсхолдеры и изменение их свойств видно сразу. Если есть желание можно попробовать вместе.

НО! Как там с поиском если нет базы

Кеширование же или индексация. Конкретно, как у них реализовано и реализовано ли не смотрел, но у себя проблему решаю именно так. Документ поменялся — или в БД его в кеш или в SphinxSearch в индекс :)

Далее есть проблема - сайты создаются для клиента.

Это особый случай.

В качестве БД планирую использовать монгу.

Привязка к конкретной БД — это всегда плохо :) БД должна быть сменным модулем.

БД должна быть сменным модулем.

У этого подхода есть серьёзный недостаток — ты ограничин функционалом общим для всех поддерживаемых БД. Т.е., БД превращается в очень примитивное хранилище что не всегда есть гуд. Я поэтому люблю sqlalchemy и постгрес — у меня сразу всякие массивы, json, fulltext search, констрейнты и прочее уже есть средствами СУБД.

У этого подхода есть серьёзный недостаток — ты ограничин функционалом общим для всех поддерживаемых БД.

А чего не хватает? Документ — объект. Любые параметры документа можно сохранить в любом бэкенде. Всё остальное — это уже дело не документа, а обвязки.

у меня сразу всякие массивы, json, fulltext search, констрейнты и прочее уже есть средствами СУБД.

Зачем документу в общем случае «JSON» и «констрейны»?

Fulltext search средствами БД — это вообще только для мелких решений. Никакая БД не заменит Sphinx или Elastic.

А чего не хватает?

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

Зачем документу в общем случае «JSON» и «констрейны»?

эффективная реализация того же поиска, индексов, вот это все.

или что, ты считаешь что надо меряться скоростями однотабличных селектов? :)

Кеширование же или индексация. Конкретно, как у них реализовано и реализовано ли не смотрел, но у себя проблему решаю именно так. Документ поменялся — или в БД его в кеш или в SphinxSearch в индекс :)

Ну так ведь они говорят БД нет...

Привязка к конкретной БД — это всегда плохо :) БД должна быть сменным модулем.

Согласен. Вопрос в том, что объекты могут быть сложными. Можно их и в blob класть. А пока это оверинжениринг

Можно их и в blob класть.

говнорешение же.

Fulltext search средствами БД — это вообще только для мелких решений. Никакая БД не заменит Sphinx или Elastic.

Тут 2 вопроса. 1) Как ты собираешься реализовать бэдж с количеством комментариев к статье без поиска? 2) Начали мы с ЛЕГКОВЕСНОЙ CMS и тут хрясь эластиксеарч. Прямо велосипед с прицепом где вертолет, бетономешалка и экскаватор, а на веревочке еще и атомный ледоход.

Ага. Именно. Потому пока монго. А там видно будет. Я кстати очень PostgreSQL люблю, но не хочу чтоб объедки знали где они хранятся....

Ну так ведь они говорят БД нет...

Для работы не нужна. Для кеширования — пожалуйста. Широкий выбор в виде плагинов.

Как ты собираешься реализовать бэдж с количеством комментариев к статье без поиска?

А зачем поиск для количества комментариев? Оно вообще в метаданных может храниться. Тем более — в кеше.

Начали мы с ЛЕГКОВЕСНОЙ CMS и тут хрясь эластиксеарч.

Она очень круто расширяема. Кому нужно несколько страничек, тому хватит и без Эластика :)

Прямо велосипед с прицепом где вертолет, бетономешалка и экскаватор

Тебя пример Linux'а не смущает? :) Который живёт от встраиваемых систем до суперкомпьютеров...

Попался приличный список flatfile CMS, среди которых есть ещё примеры Markdown. Но Grav, похоже, самый активный и функциональный, с самым большим коммьюнити

https://github.com/ahadb/flat-file-cms

А зачем поиск для количества комментариев? Оно вообще в метаданных может храниться. Тем более — в кеше.

Порочный путь. Так в каждом комментарии мы должны хранить ID кого комментируем, а в метаданных ВСЕ ID кто комментирует. Что произойдет если модератор удалит комментарий?

Все эти связи между объектами начинают рости как снежный ком.

Должен признать, что монга тут не самое хорошее, но всетаки поиск там есть.

А про Linux. Ну так у нас получится, что даже в простых случаях мы имеем проблемы. Например как ты реализуешь меню сайта? (О нас, Продукты, Контакты.....). Хранишь ты ID в метаинформации, а тут ID пропал. А если меню 2. Одно слева (список статей), а второе сверху.

Вот и получается, что легковесная CMS в реальной жизни потребует уже побольше. Хотя спорить сильно не буду. Пока я хороших CMS не видел (почти).

или что, ты считаешь что надо меряться скоростями однотабличных селектов? :)

А в CMS надо сильно много таблиц для контента? Не, можно конечно обмазаться левыми джойнами и сидеть ждать выдачи минутами, пока посетители не разбегутся в ужасе. А что, процы сейчас мощные, диски быстрые.

Ну CMS CMS рознь. Некоторые плодят по таблице для каждого типа содержимого. 1 для текста 1 для картинок 1 для карты......

Ну Ok, это всего три таблицы + ещё одну для отношений, если в лоб. Я в 1C насмотрелся сикль-запросов по 30-40 кБ когда-то. С тех пор из-за высокого TTFB сильно комплексую.

Ну не надо на ночь глядя называть 1С...

Так в каждом комментарии мы должны хранить ID кого комментируем

Конечно.

а в метаданных ВСЕ ID кто комментирует

Тогда это ты уже какую-то другую задачу описываешь. Только что ты писал только про счётчик комментариев.

Все эти связи между объектами начинают рости как снежный ком.

Ну, не знаю. Я в рамках Infonesy их вообще от нод отвязал :) Статья может быть написана на одной ноде (отдельном сервере), комментарий к ней — на другом. И всё это связывается на произвольном транспорте (у меня сейчас для простоты и унификации это JSON/Markdown через BTSync/Syncthing).

Хранишь ты ID в метаинформации, а тут ID пропал.

Системное меню не может относится к метаданным объекта. Это метаданные системы.

в CMS надо сильно много таблиц для контента?

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

обмазаться левыми джойнами и сидеть ждать выдачи минутами

индексы?

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

Пользователь уж точно не с маркдаун. А про Метаинформацию - возможно придется делать по ней поиск.

Индексы такая штука, что или их ручками создавать или повеситься...

их ручками создавать

ммм... а как иначе? :)

Ну всякие обьектны БД умеют это, но .... Это не то ради чего надо корячиться.

Это не то ради чего надо корячиться.

ты пишешь на пхп?

ты пишешь на пхп?

Акстись...

Типа как jekyll/hakyll и прочее? Их же вроде прорва?

существенную разницу с моими решениями

Это с какими? Open source?

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

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

Эта штука хорошо вписывается в концепцию интересной для меня проблемы распределённой соцсети :) Если б не их нестандартная для html методика работы с относительными путями и концевыми слешами... :-/