В начале Осени

2026-02-06T00:00:00+00:00

В этой главе мы увидим основные идеи, стоящие за новой CMS (кодовое имя «Осень»). Из этого хаотичного наброска вырастет цельное представление о том, что мы хотим реализовать. Основная идея — создать простую в обращении и обслуживании, продуманную и отполированную систему в духе Ghost и Craft, но добавить больше инструментов редактирования и представления контента. Это позволит использовать CMS изданиям, требующим большего, чем просто блог.</p>

Одновременно мы хотим избежать хаоса и тяжёлого наследия прошлого, которым страдает WordPress. Вопрос кастомизации должен быть продуман с самого начала, но конкретная форма требует дополнительного исследования.</p>

Существующие решения</h2>

WordPress</h3>

Ghost</h3>
Он классный, но в нём не хватает нескольких компонентов:</p>

Публикации на нескольких языках</li>
Шаблонов для разных видов публикаций, который могут потребоваться онлайн-изданию (новости, интервью, эссе, репортажи, около-академические статьи)</li>
Интеграции с соцсетями, не распространёнными на Западе</li>
Интеграции с платёжными системами, не распространёнными на Западе</li> </ol>
Craft CMS</h3>
Craft CMS</a></p>
Публикация, ключевой элемент</h2>

</div> </figure>
Метаданные</h3>
Авторы.</strong> Нам нужна гибкая настройка авторов — их может быть несколько и они могут отличаться между версиями на разных языках.</p>
Переводчики.</strong> Указывать авторство перевода это хороший тон.</p>
Иллюстраторы.</strong> Иногда иллюстрации могут быть не менее важной частью публикации.</p>
Редакторы.</strong> Если это большая статья, то она может быть результатом коллективной работы и редакторы тоже могут быть указаны.</p>
Тэги.</strong> Категоризация публикаций.</p>
SEO</strong>. Заголовок, описание и микроформаты для поисковиков и социальных сетей.</p>
Связи между публикациями.</strong> Публикации могут быть объединены в серии или представлять собой онлайн-дискуссию.</p>
Даты.</strong> Дата создания, последнего изменения и публикации.</p>
Внешние связи</strong>. Если публикация была также опубликована в соцсетях и других внешних источниках, мы должны сохранить эту связь, хотя бы в виде ссылки.</p>
Документ</h3>
Сам документ должен хранится в формате, который отвечает нескольким требованиям:</p>

Поддерживает совместное редактирование (Automerge</a>)</li>
Поддерживает шаблоны для вёрстки контента</li>
Позволяет эффективно представить контент в виде HTML с дополнениями в виде веб-компонентов</li> </ul>
Компоненты системы</h2>
Редактор, в котором хочется писать</h3>
Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».</p>
Базовое форматирование</h4>
Редактор должен поддерживать базовое форматирование (курсив</em>, полужирный</strong>, таблицы и т.д.). Администратор должен иметь возможность настроить доступные редактору возможности форматирования для сохранения общего стиля издания. К примеру, отключить выделение разными цветами или ограничить палитру цветами бренда.</p>
Блочное редактирование</h4>
Документ разбит на сегменты, которые инкапсулируют свой контент в универсальный контейнер. Внутри может быть параграф текста, заголовок, изображение, произвольный HTML и т.д.

Виды сегментов</summary>

Параграф</li>
Разделитель</li>
Закладка (Ссылка с изображением и предпросмотром, аналогичная preview в соцсетях)</em></li>
Разделение на публичную/закрытыю часть</li>
Call to Action/Ad</li>
Email content</li>
Callout/Hero</li>
Header</li>
Signup</li>
Toggle</li>
Video</li>
Audio</li>
File</li>
Product</li>
HTML</li>
Markdown</li>
Картинка</li>
Галерея</li>
Кнопка/Группа кнопок</li>
Вставки
Youtube</li>
X</li>
Unsplash</li>
Vimeo</li>
CodePen</li>
Spotify</li>
SoundCloud</li>
Telegram</li>
Custom</li> </ul> </li> </ul> </details> </p>
Сегмент можно перемещать по документу. Сегмент можно расположить в зоне шаблона.</p>
Шаблоны</h4>
К документу можно применить шаблон, который описывает какие сегменты могут быть в документе и как они расположены. К примеру, шаблон «Интервью»</strong> содержит в себе сегменты «Вопрос» и «Ответ» помимо сегментов по умолчанию, таких как параграф.

400px) and (width <= 800px)" type="image/avif" > 800px)" type="image/avif" > </picture> </a>
Выбор сегмента в шаблоне интервью</figcaption> </div> </figure> </p>
Шаблоны могут также описывать вёрстку и расположение сегментов относительно друг друга для создания более динамичной структуры контента.

400px) and (width <= 800px)" type="image/avif" > 800px)" type="image/avif" > </picture> </a>
Шаблон в вёрсткой в две колонки</figcaption> </div> </figure> </p>
Нам нужна спецификация и API для создания и использования блоков. Это позволит создавать специализированные продукты для разных сегментов рынка и, в будущем, позволит пользователям создавать собственные шаблоны.</p>
Предпросмотр</h4>
Редактор должен быть реализован таким образом, чтобы использовать стили темы и сделать оформление в процессе редактирования максимально близким к отображению публикации на сайте. Для этого надо реализовать загрузку стиля из темы, установленной администратором сайта. Отдельно нужен полноэкранный предпросмотр в двух режимах — мобильный и десктоп.</p>
Вопрос Markdown</h4>
В Ghost можно вставить Markdown отдельным блоком, который будет распознан и трансформирован в HTML. Хотим ли мы сделать также или стоит создать отдельный режим редактирования для Markdown, в котором редактор будет трансформировать Markdown на лету (как, к примеру, в Obsidian)?</p>
Всё для перевода</h3>
Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.</p>
Перевод интерфейса</h4>
Система должна предоставлять возможность добавить перевод любых строк в интерфейсе и набор функций для более глубокой локализации (форматы дат и единиц измерения, варианты множественного числа) Переводы должны хранится в одном или нескольких файлах (чтобы загружать их отдельно по необходимости). В будущем нужно предоставить интерфейс для загрузки перевода и базовой проверки на полноту. Возможно, в будущем можно предоставить механизм автоматического перевода, но это требует дополнительного исследования вопроса.</p>
Перевод контента</h4>
Каждая сущность в системе (публикация, автор и прочие создатели, тэг и т.д.) должна иметь версии на разных языках и собственный набор связей с другими сущностями. Публикации на разных языках могут иметь разный набор тэгов, авторов и переводчиков, могут попадать в разные категории, если издание имеет разный набор категорий на разных языках. В связи с этим, каждая языковая версия должна быть отдельной записью в базе данных, связанной с сестринскими версиями отдельным уникальным идентификатором.

структура тэгов на разных языках</em> </div> </figure> </p>
Перевод публикаций</h4>
«Осень» должна предоставлять удобный интерфейс для перевода контента. Каждый перевод это отдельный документ со своими авторами, переводчиками, иллюстраторами и т.д., датами публикации и т.д. Как указано выше, каждая языковая версия публикации должна быть отдельной записью в БД и иметь общий уникальный идентификатор.</p>
Переводы должны быть интегрированы в процесс работы и интерфейс.</p>
Списки сущностей должны иметь фильтр по языку.

список публикаций отфильтрованных по языку</em> </div> </figure> </p>
Каждая публикация должна ясно показывать, на какие языки она переведена.

языки на которые переведена публикация</em> </div> </figure> </p>
Создание перевода должно быть легко доступно из интерфейса публикации.

интерфейс создания перевода</em> </div> </figure> </p>
Редактор должен поддерживать продвинутые методы работы с переводом. Две версии рядом друг с другом

две версии перевода рядом друг с другом</em> </div> </figure> </p>
Предложение автоматического перевода с возможностью редактирования

автоматическая и окончательная версии перевода рядом друг с другом</em> </div> </figure> </p>
Интерфейс с оригиналом, переводом и предложенным автоматическим переводом

оригинал, окончательный и автоматический перевод рядом друг с другом</em> </div> </figure> </p>
Инструменты редактора</h3>
Для эффективной работы онлайн-издания CMS должна поддерживать гибкий рабочий процесс, где каждая публикация может проходить через несколько этапов перед публикацией.</p>
Процесс производства и публикации</h4>
Публикация начинается с черновика, который доступен только в административном интерфейсе.</p>
Далее черновик может быть переведён в статус "готово" и ожидать публикации. Здесь нам нужен интерфейс для обсуждения и редактуры материала, который включает в себя:</p>

Комментирование, привязанное к отдельным разделам материала</li>
Обсуждения (треды) по каждому комментарию</li>
Предложения изменений, которые могут быть приняты или модифицированы автором</li> </ol>
После того, как работа закончена, материалу назначается время публикации, включая публикацию немедленно, к определённому времени, или в специальный режим "ожидания", когда материал публикуется по триггеру, ручному или автоматическому.</p>
Статусы публикации:</p>

Черновик</strong>. Назначается при создании нового материала</li>
Готов</strong>. Назначается, если материал требует этапа редактуры и не публикуется немедленно.</li>
Ожидает доработки</strong>. Назначается, если редактор вернул материал на доработку автору.</li>
Ожидает публикации</strong>. Назначается, если материалу назначено время публикации в будущем.</li>
До звонка/по триггеру</strong>. Назначается, если материал должен быть опубликован по триггеру.</li>
Опубликован</strong>. Назначается, когда материал опубликован в открытый доступ.</li>
Отозван</strong>. Назначается, когда ранее опубликованный материал отозван.</li> </ol>
Описанный выше порядок работы это "программа-максимум". Администратор сайта должен иметь возможность выбрать несколько вариантов порядка работы — "полный", "упрощённый" или какую-либо ещё комбинацию статусов.</p>
Доступ для внешних авторов</h4>
CMS должна иметь возможность предоставить доступ к редактированию одной публикации для внешнего автора и последующего обсуждения при редактуре. Для этого может потребоваться специальная роль и возможность авторизации через внешние источники, которые поддерживают OAuth и аналогичные механизмы.</p>
Совместная работа</h4>
Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.</p>
Расписание публикаций</h4>
«Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.</p>
Версионирование</h4>
Каждое изменение статуса публикации создаёт новую версию. Система должна предоставлять механизм для просмотра истории версий и изменений между версиями.</p>
Доставка контента</h3>
HTML страницы</h4>
JSON API</h4>
RSS и Atom</h4>
Интеграции</h4>
SEO</h4>
Микроформаты</h4>
Аналитика</h3>
Платежи и подписки</h3>
Роли, права и доступы</h3>
Структура данных</h2>
Публикации</h3>
Ресурсы</h3>
Рендеринг HTML и API</h2>
CMS должна предоставлять серверный рендеринг HTML и REST API — публичный для отображения контента используя фронтенд пользователя и закрытый за авторизацией для административной панели.</p>
Возможно, нужно предусмотреть возможность отделить модуль рендеринга HTML и запустить его вместе с веб-сервером на Edge-воркерах и подобных системах, получая при этом контент из базы данных через API. Насколько это востребованный и полезный функционал пока неясно.</p>
Федерация</h2>
ActivityPub</h3>
ATProto</h3>

Компоненты системы</h2>

Редактор, в котором хочется писать</h3>
Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».</p>

Всё для перевода</h3>
Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.</p>

Совместная работа</h4>
Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.</p>

Расписание публикаций</h4>
«Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.</p>

Доставка контента</h3>

HTML страницы</h4>

JSON API</h4>

RSS и Atom</h4>

Интеграции</h4>

SEO</h4>

Микроформаты</h4>

Аналитика</h3>

Платежи и подписки</h3>

Роли, права и доступы</h3>

Структура данных</h2>

Публикации</h3>

Ресурсы</h3>

Федерация</h2>

ActivityPub</h3>

ATProto</h3>

Общие принципы</h2>
Рассмотренные здесь редакторы воплощают несколько общих базовых подходов, на которых сошлись как на оптимальных:</p>

Conteditable как база</h3>

Lexical</h2>

Quill</h2>

ProseMirror</h2>

Редакторы на основе ProseMirror</h3>

TipTap</h4>

ProseBlock</h4>

CKEditor</h2>

В начале Осени

Существующие решения</h2>

WordPress</h3>

Craft CMS</h3>
Craft CMS</a></p>

Редакторы текста в Вебе

В начале Осени

Существующие решения</h2>

WordPress</h3>

Craft CMS</h3> Craft CMS</a></p>

Компоненты системы</h2>

Редактор, в котором хочется писать</h3> Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».</p>

Всё для перевода</h3> Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.</p>

Совместная работа</h4> Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.</p>

Расписание публикаций</h4> «Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.</p>

Доставка контента</h3>

HTML страницы</h4>

JSON API</h4>

RSS и Atom</h4>

Интеграции</h4>

SEO</h4>

Микроформаты</h4>

Аналитика</h3>

Платежи и подписки</h3>

Роли, права и доступы</h3>

Структура данных</h2>

Публикации</h3>

Ресурсы</h3>

Федерация</h2>

ActivityPub</h3>

ATProto</h3>

Редакторы текста в Вебе

Общие принципы</h2> Рассмотренные здесь редакторы воплощают несколько общих базовых подходов, на которых сошлись как на оптимальных:</p>

Conteditable как база</h3>

Lexical</h2>

Quill</h2>

ProseMirror</h2>

Редакторы на основе ProseMirror</h3>

TipTap</h4>

ProseBlock</h4>

CKEditor</h2>

Craft CMS</h3>
Craft CMS</a></p>

Редактор, в котором хочется писать</h3>
Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».</p>

Всё для перевода</h3>
Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.</p>

Совместная работа</h4>
Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.</p>

Расписание публикаций</h4>
«Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.</p>

Общие принципы</h2>
Рассмотренные здесь редакторы воплощают несколько общих базовых подходов, на которых сошлись как на оптимальных:</p>