Управление контентом на основе Git?

Я ищу Ruby CMS (или плагин), который может обслуживать и редактировать контент, расположенный в репозитории Git. Меня тошнит от того, что мой контент в дБ. Пользователи, настройки, комментарии, отлично. Но не больше контента.

Каждое живое редактирование на странице должно быть автоматически, немедленно зафиксировано, чтобы предотвратить необходимость объединения на стороне сервера. Кроме того, при каждом нажатии на новые изменения они должны быть немедленно обновлены в файловой системе.

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

Я читал о GitModel и git -blog, но я все еще ищу кое-что, что соответствует моим потребностям немного ближе. [EDIT: GitModel слишком сложно редактировать вручную, когда используется с большинством CMS, а git -blog использует статическое создание файлов.]

EDIT: мое смещение против баз данных для контента относится только к сайтам, которым требуется высокая степень настройки, и не может использовать CMS как есть. Сайты, чей код развивается так же, как и его содержимое. Это когда контент в БД является полным кошмаром. Когда вам нужно одновременно разворачивать содержимое и код, они объединяют их обоих в производство позже. БД не ветвятся и не объединяются.

У меня такой сайт.

Аргумент производительности в пользу содержимого только для БД недействителен. Я написал CMS 5 лет назад, который синхронизирует базу данных с файловой системой, где файловая система всегда является главной копией. Он легко масштабируется до 100 000 страниц, поддерживая время отклика 10 мс и время повторного использования 2 с. Полностью доступные для поиска индексы всего содержимого, метаданных, тегов, дат и т.д. И, черт возьми, я написал это в самой медленной, самой мучительной структуре на планете, ASP.NET. Фактически это почти сделало ASP.NET приемлемым, и он отлично обслуживал различные компании, поскольку у них был такой же сайт, как упоминалось выше.

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

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

До сих пор, ближе всего я пришел, используя Cloud9 для редактирования репозитория контента Git (Nesta CMS), а затем нажмите изменения в командной строке. Он медленный, но, по крайней мере, он основан на веб-интерфейсе, если моя dev-машина не удобна, и я обнаружил, что я ошибся своим именем в статье. Ищем лучшие варианты.

Ответ 1

Я закончил реализацию микро-CMS под названием Hardwired, которая отлично справляется с моей задачей.

Попробуйте.

Ответ 2

Gollum (https://github.com/github/gollum) - это Git -листная вики, написанная GitHub в Синатре. Вы можете нажать и вывести из командной строки или использовать встроенный веб-интерфейс для редактирования содержимого.

К сожалению, похоже, что у GitHub есть кое-какие отказы от разработки/обслуживания, поэтому у него есть некоторые грубые грани. Он также очень прост, поэтому он не включает такие функции, как аутентификация [1].

Я собираюсь использовать Gollum с сайтом gollum (https://github.com/dreverri/gollum-site), статическим генератором файлов для Gollum и просто использовать Gollum в качестве бэкэнда администратора.

1: базовое решение для аутентификации можно найти на https://github.com/github/gollum/issues/107#issuecomment-2608061

Существует также Regulate, https://github.com/quickleft/regulate:

Двигатель Rails 3, обеспечивающий Git поддерживаемую CMS, которая позволяет администратору определять редактируемые области в представлении страницы.

Ответ 3

Ваше решение может быть слишком запутанным позже, и позже у вас может быть больше головных болей.

Я советую: (1) Использовать NoSQL, например MongoDB. (2) Перенесите все данные из предыдущего БД. (3) Затем поставьте свою БД под управлением версиями. Вы можете, поскольку он основан на документе, а не на SQL.

У Монго тоже отличный Gem, называемый MongoID https://github.com/mongoid/mongoid

Таким образом, вы можете использовать CMS, который имеет гораздо большее сообщество (например, НПЗ). Кроме того: ваши резервные копии базы данных решаются легко, потому что вы можете откатываться в любое время с помощью Git или просто клонировать вашу БД иногда, также вы можете автоматизировать резервное копирование и т.д.

НТН

Ответ 4

Возможно, вы могли бы объединить обертку git для редактирования и т.д.:

https://github.com/schacon/ruby-git

с вашим собственным кодом рендеринга на основе простой файловой системы хранения.

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

Этот комментарий, который вы делаете, "большая часть моего сайта будет содержать расширенные динамические функции", похоже, вам нужно будет свернуть свое собственное решение на основе ваших уникальных требований.

Ответ 5

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

Если проблема заключается в том, что пользователи перезаписывают записи, вам следует скорее добавить функциональность для архивирования предыдущих версий (или их разности), не перезаписывая их. Например, камень rails_admin делает это

И даже при немедленной фиксации вы не избежите проблемы, когда один пользователь открывает запись для редактирования и удерживает ее в течение часа, пока он не сохранит ее, где в то же время другой пользователь делает быстрое редактирование через 5 минут. Здесь вам нужно отправить от клиента, какая редакция он редактировал, а в случае конфликта - показать интерфейс, в котором пользователь может сравнить свои версии с теми, которые сделал другой пользователь. Или, если вы продвинулись, вы можете сделать это способом google-docs. включить одновременное редактирование.