CMS с API и синхронизацией

Я пытаюсь спроектировать очень специфическое решение CMS, и до сих пор мне не хватало наиболее популярных вариантов.

В частности, мне нужна CMS, которая

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

Я чувствую, что изучил большинство вариантов, но я не очень уверен, что изучил их все, любые предложения будут очень признательны!

(В Drupal 7 есть известные решения для этих условий, но если это не Drupal 8, это не вариант. Ожидание завершения этих функций/модулей в Drupal 8 также не вариант.)

Вы пробовали cmsmatrix.org ? Это всегда мое место для CMS
Drupal никогда не вариант!
Пожалуйста, подробно опишите, что вы пытались сделать, чтобы не тратить чужое время впустую.

Ответы (5)

Я понимаю, что кто-то уже опубликовал это предложение, но вы буквально только что описали Liferay. Почему Java не работает? Несмотря на то, что основная кодовая база Liferay написана на языке Java, огромное количество конфигураций и настроек можно выполнить без написания кода.

Кроме того, пользовательские плагины могут быть написаны на десятках разных языков благодаря JSON HTTP API, хотя большая часть документации написана для Java.

Учитывая ваши первоначальные требования, вам будет очень тяжело, если вы не захотите работать с Java. Экосистема с открытым исходным кодом Java большая и зрелая. Кроме того, язык всегда был в пространстве CMS, и если вам действительно нужны широкие возможности настройки, это может быть вашим единственным реальным вариантом. Также имейте в виду, что Liferay и некоторые ее конкуренты огромны, а знания, необходимые для создания сложных систем, пугают. Хотя вы можете стать профессионалом, может быть, за год или два, буквально может потребоваться десятилетие, чтобы накопить опыт.

Если вы готовы к выбору J2EE , существует Liferay Portal . Существует версия FOSS, которая может быть настроена с произвольными макетами, как вы описываете, и, что важно, для промежуточного хранения и импорта/экспорта между установками.

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

Облачные, на мой взгляд, самые лучшие. Я думаю, что они наиболее просты в использовании и навигации, особенно с учетом того, что в настоящее время многие люди используют облачные решения. Tractfile — отличный пример. Я знаю несколько компаний, которые его используют, им это нравится.

Если я вас правильно понял, это очень похоже на то, что мы делаем прямо сейчас на нашем сайте, и мы используем Drupal 8. Я не уверен, какие ограничения, по вашему мнению, есть у D8 для вашей конечной цели?

Что касается контента, мы используем источник домена и доступ к домену, чтобы сделать контент пригодным для использования во всех или некоторых доменах. У нас нет основного сайта, вместо этого все сайты настроены как дополнительные домены.

Я упоминаю об этом, потому что мне интересно, если у вас есть опыт работы с Drupal, возможно, вам будет проще работать с тем, что вы знаете, чем пытаться изобрести велосипед снова и снова.

Drupal невероятно медленный, для начала?
@ user3791372: Drupal используется в реальном мире для обеспечения работы быстрых веб-сайтов, поэтому вам нужно будет развить свой аргумент или удалить его, если он не имеет отношения к вопросу. Спасибо!
я верю вашему половинчатому утверждению: «в реальном мире drupal используется для обеспечения работы быстрых веб-сайтов», но оно продолжает «... и делает их медленными». У меня есть «реальный опыт». Если вы считаете, что это быстро, чем хорошо для вас. Я бы никому не посоветовал его использовать. Инфраструктура - шутка, коммьюнити претенциозное, код невероятно плохой, а производительность хуже, чем все три в квадрате, но, конечно, у всего есть свои фанбои.

Drupal 8 был претендентом на победу, в основном потому, что он имеет большую часть того, что я искал через модули. (Создание CMS также было очень реальной возможностью.) Однако, поскольку большинство этих модулей Drupal в то время все еще портировались из Drupal 7, и поскольку на меня были наложены ограничения, касающиеся временных рамок и т. д., мне в конечном итоге пришлось остановиться на основе WordPress. решение.