LiveStreet CMS

В имеющемся свои грабли наложены. Типа, слоя абстракции для БД, не дотягивающий до полноценной ORM, или системы расширения классов на пхпшной магии. На этом выстроен большой объём кода, который не переписать и не выкинуть.

Хм, мне кажется, тут немного другое деление. Есть люди, которые умеют делать простые посты и им не требуется сложного инструментария. Написать текст и вставить картинку — предел потребностей. Они могут делать это в ворде, могут в CodeX. Разницы никакой. И есть люди, которым нужно делать сложные публикации с красивым форматированием, оформлением иллюстраций, выделением разделов, элементами для привлечения внимания, вроде цитат, и даже интерактивом. В рич-едиторе это делать тяжело. Но можно. Зачастую, приходится лезть в хтмл, чтобы получить нужный результат. Тем, кто готов идти на такие усилия ради результата, перейти на редактор с блоками, позволяющий делать нужное быстрее и проще, проблемой не будет. Наоборот, будут только рады.
Единственный проблемный юзеркейс таков — знаю блоггеров, которые постят в ЖЖ, потом копируют html и вставляют его в LS. Им удобно делать такие репосты. С блоками так легко из ЖЖ уже не повставляешь.

Да, они гибче и удобнее. Решают проблему с катом — не нужно использовать специальный разделитель, можно делать автоматический кат по первому блоку. Решается проблема с иллюстраций поста — можно брать картинку из первого блока-картинки. Не нужно учить юзеров вёрстке, чтобы они красиво оформляли, к примеру, цитаты и подписи к иллюстрациям — это делается через форму. Нет сложностей со вставкой в пост навороченных элементов, типа галереи или опроса. Конфиг у tidy или jevix проще, потому что нет нужды нагружать html поддержкой всевозможных фишек. Короче, одни плюсы.

А, и ещё — тут некоторые ждут каких-то решений от Максима, а он молчит и ничего не решает. Предлагаю выходить из этой ситуации таким образом: писать пост или коммент с конкретным вопросом или предложением к Максиму, и, обязательно, своим вариантом решения. Если Максим никак не комментирует, скажем, в течении суток, считать, что он не против этого варианта и поддерживает его. Просто чтоб на месте не топтаться и не перекладывать ответственность на того, кто не хочет брать.

Ну и по поводу выборов фреймворка. Это важный вопрос, но только вести его следует таким образом, чтобы в итоге можно было прийти к решению. Можно спорить долго, аргументировать за и против любого варианта, бесконечно, в итоге так ничего и не начать делать.
Предложение — наконец-таки создать точку приложения усилий. Сделать на гитхабе организацию deadstreet-team (название обсуждаемо), цель которой — написание движка (или движков) для сообществ и коллективных блогов. Чтобы любые индивидуальные и групповые проекты в это области находились в одном месте и были видны. Внутри — репозитарий для ТЗ и прочей проектной документации. Сбор идей и предложений — там же. Коллекция ссылок на аналогичные проекты — там же. Спецификация API, если вдруг таковая родится — там же.
Далее, желающие делать движок на Laravel создают репозитарий laravelstreet, желающие делать его на Symphony — symphonystreet, и пилят внутри них минимальные рабочие прототипы. Кто быстрее запилит и больше контрибьюторов привлечёт — тот и победил. Может быть даже в процессе появится полезный абстрактный framework-agnostic-код, который можно будет разделить.

Кстати, сейчас в блогах писать посты в рич-эдиторе не модно, в моде редакторы, где пост — это список блоков разных типов: текст, картинка, цитата и т.п., наподобие CodeX. Когда будете писать движок, закладывайте сразу такой формат поста. Чтоб потом не было мучительно больно переделывать.

Люди не поддерживают example

В каком месте появилось убеждение, что делая систему начиная со спецификации API, можно сделать только example, но не продукт?

Я исхожу из такой архитектуры — фронтэнд целиком перемещается на клиент, шаблонизаторов нет вовсе, а на бэкэнде остаётся только REST API. В результате, фронтэнду не важно, на чём реализован бэкэнд, а бэкэнду — какой используется фронтэнд.

Это просто заготовки. Неужели так сложно это понять?

Я это понимаю. Ты зачем-то пытаешься доказать мне то, с чем я и так согласен. )

Пишите спецификацию и ждите у моря погоды. Вы уверенны в том, что за вас все сделают.

Ну, я предложил план действий, как начать работу над новым движком. Первый шаг — название, репозитарий, ТЗ. Можно нулевой шаг добавить — пост в этом сообществе с анонсом и приглашением. Наберётся человек пять, и можно начинать. Твои предложения какие? Максима ждать?

Никому не нужен example для учебных целей.

Ты опять споришь не с тем, что я предлагаю. Я не предлагаю писать example для учебных целей. По поводу «никому не нужен» — не соглашусь, там по две тысячи звёзд на репках.

Откройте для начала репозитории и посмотрите коммиты.

Открыл, посмотрел. Да, на реакте и ангуляре основной контрибьютор — Эрик Симонс. На других — другие.

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

Разумеется. Только потому, что есть спецификация, никто движок писать не будет. Но если будет спецификация, вариант бэкэнда, вариант фронтэнда, рабочая сборка, которой люди пользуются, велик шанс, что кто-то будет форкать отдельные части и переписывать под себя. Шансов же, что кто-то будет переписывать под себя монолитный проект без спецификации — нулевой.

Это не имеет совершенно никакого отношения к LiveStreet.

Имеет, потому что это всё одно семейство со схожим функционалом.

Да, RealWorld — это просто стандартное демо для разных платформ. Сугубо для учебных целей. Которое нет нужды доводить до уровня готового продукта, релизить в продакшен и использовать для практических нужд. Главное в другом — его автор не занимается реализацией всех этих вариантов. Он только описал задачу и спецификацию API. Дальше всё делают люди, которым захотелось реализовать её определённым образом.
Для нашей задачи спецификация будет побольше и посложнее. Кто и на чём будет её реализовывать — я не знаю. Может будет один вариант реализации, может несколько, с разными авторами и названиями. Может, из нескольких вариантов большинство будет хреновыми и умрут, но один или два окажутся жизнеспособными и разовьются.
У меня цель простая — я хочу современную замену LS с функционалом примерно как у Tjournal, с открытым кодом, которую я смогу бесплатно поставить себе на сервер. Как потребителю, мне всё равно, на чём оно будет реализовано. Лишь бы было и работало.

Хорошо, но на гитхабе нельзя сделать организацию «любое-условное-название-team». Нужно что-то конкретное.

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

Никто не будет вам тянуть десятки технологий.

Я не совсем понимаю, как ты понимаешь мою идею. Мне кажется, несколько превратно, из-за чего споришь с чем-то совсем другим, не тем, что я имею в виду. Разумеется, никто не будет тянуть десятки технологий. Я ж этого и не предлагаю. )

> Никто не будет вам тянуть десятки технологий.

Для начала нужно рабочее название, репозитарий и ТЗ, чтоб кор разработчикам было куда вступать и что реализовывать. И, если это новый проект, нет смысла воспроизводить в нём LS, копируя его со всеми недостатками. Можно сразу сделать его лучше.

В этом есть логика для того, чтобы проектом занимался не один человек, релизы с фишками выходили не раз в три года, и всё это дело не умерло, когда Laravel выйдет из моды.

Вряд ли. Мне больше нравятся рельсы, нода, голанг и реакт. Но контрибьютором ТЗ и спецификации API я быть готов.

Отлично, давай рабочее название придумаем и начнём писать ТЗ. )

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