LINUX.ORG.RU
ФорумTalks

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

 , , , ,


8

5

(интересно, что на ЛОРе нет подходящего раздела, где можно поделиться интересным найденным софтом, который на ЛОРе раньше не рассматривался :) )

Так вот,попалось очень интересное решение, которое процентов на 80 пересекается с моими идеями и разработками:

Grav CMS

https://getgrav.org/

— CMS базируется на плоских файлах в Markdown формате (для ускорения опционально возможно кеширование «поверх»).
— Хотя наличествуют и традиционные способы установки, рулит реализация всего на Composer.
— Большое количество плагинов и тем (Twig).
— Запускается в базовом варианте сразу, без всякого конфигурирования.
— Есть свой пакетный менеджер для расширений/тем.
— Расширения/темы можно ставить через админку (хотя первый раз она ставится отдельным пакетом).
— Мультисайты, многоязыковость, ЧПУ, роутинг, редиректы
— Система пользователей и прав (хотя не разбирался, есть ли возможность коллективной работы).
— Контент может браться из Git, SVN, Dropbox и других. В т.ч., например, текст страниц может быть прямо на GitHub.

Моя идея «поправил файл дома, он через SparkleShare автоматом ушёл на GitHub, GitHub дёрнул сайт и вот страница уже на сайте», т.е. «правлю Markdown-файл дома в файловой системе — обновляется удалённый сайт» тут, кажется, уже работает.

Забавно, что формат метаданных в Markdown практически совпадает с моим :) Т.е. большинство моих тестовых страничек в этой CMS будут работать как есть.

Небольшие нестыковки с моей системой по структуре имён файлов, расположению картинок и т.п. У меня логичнее :)

Надо будет подумать. То ли эту CMS как есть на мои новые сайты ставить, то ли просто в роли бэкенда/миддлэнда (админка, редактор файлов, благо, он хорошо сделан, а фронт уже мой). В любом случае система заслуживает внимания :)

Редактор:

http://ipfs.pics/ipfs/QmSmh9w2GdMfH3tNwurUwwD66rPBsuvsHKb2iJoDZaEizC

Результат:

http://ipfs.pics/ipfs/QmT6fFomsx8rN2N6Zv5pHNE7KE96vgexX8qKicjjrzZsXb

Вот в чём заметил существенную разницу с моими решениями — это в системе путей. У них каждая страница — это файл. Оканчивается без слеша на конце. В HTML такое поведение нередко порождает путаницу, поэтому у меня каждая страница — это каталог. Т.е. у меня все встроенные элементы лежат уровнем ниже, у них — на том же уровне, что и страница. Поэтому совсем без конвертации, к сожалению, контент нельзя использовать там и там. С другой стороны, у них гибкая система плагинов, так что, может, получится адаптировать её под мою структуру штатными средствами :)

★★★★★

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

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

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

dmxrand ()
Ответ на: комментарий от dmxrand

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

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

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

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

Rastafarra ★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

dmxrand ()
Ответ на: комментарий от KRoN73

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

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

dmxrand ()
Ответ на: комментарий от Rastafarra

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

dmxrand ()
Ответ на: комментарий от dmxrand

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от dmxrand

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

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

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

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

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

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

KRoN73 ★★★★★ ()

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

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

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

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

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

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

dmxrand ()
Ответ на: комментарий от Rastafarra

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

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

imul ★★★★★ ()
Ответ на: комментарий от imul

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

dmxrand ()
Ответ на: комментарий от dmxrand

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

imul ★★★★★ ()
Ответ на: комментарий от dmxrand

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

Конечно.

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

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

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

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

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

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от imul

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

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

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

индексы?

Rastafarra ★★★ ()
Ответ на: комментарий от KRoN73

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

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

dmxrand ()
Ответ на: комментарий от Rastafarra

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

dmxrand ()
Ответ на: комментарий от Rastafarra

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

dmxrand ()

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

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

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

zabbal ★★ ()

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

CaptainFarrell ()
Ответ на: комментарий от CaptainFarrell

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

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

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.