Разработка WYSIWYG-редактора для CMS сайта

Собственный WYSIWYG-редактор мы разрабатываем, когда готовые инструменты не справляются с уникальными требованиями: нестандартные блоки, строгий выходной HTML, интеграция с бэкендом CMS. Наш опыт — 10+ лет и 50+ проектов — позволяет создавать редакторы под ключ за 3–12 недель. Мы гарантируем документацию, обучение и поддержку после сдачи.

Готовые редакторы (TinyMCE, CKEditor) часто имеют избыточную функциональность или, наоборот, не позволяют добавить специфические блоки: видео с кастомного плеера, интерактивные таблицы, встраивания из внешних сервисов. Кроме того, они генерируют грязный HTML, который сложно парсить на бэкенде. Кастомный редактор даёт полный контроль над моделью данных и выходным кодом.

Мы проектируем редактор под конкретную CMS: Laravel, WordPress, Django или кастомное решение. Контент храним в JSONB полях базы данных — это гибко и индексируемо. На выходе — быстрый, предсказуемый редактор с контекстным тулбаром, slash-командами и перетаскиванием блоков.

Сценарии для кастомного WYSIWYG-редактора

Свой редактор пишут, когда ни одно готовое решение не закрывает все требования. Типичные сценарии:

• Нестандартные блоки: кастомные галереи, интерактивные схемы, встраивание сторонних сервисов через iframe.
• Чистый HTML: нужен строгий выходной код без лишних обёрток, например, для дальнейшей конвертации в PDF или e-mail.
• Глубокая интеграция: редактор должен сохранять данные напрямую в CMS, работать с медиатекой, поддерживать права доступа.
• Производительность: при сотнях блоков на странице готовые редакторы тормозят — нужна виртуализация и ленивая загрузка.

Какой движок выбрать: ProseMirror, Slate или Lexical?

Писать редактор на голом contenteditable — путь к бесконечным багам. Выбор стоит между тремя зрелыми движками:

ProseMirror даёт максимальный контроль над моделью данных — его используют, например, в New York Times. Slate.js лучше для React-проектов, где важна скорость разработки. Lexical от Meta — самый производительный, но сообщество ещё невелико.

Как построить модель данных для редактора?

Редактор должен работать с чёткой схемой. Два популярных подхода: Flat JSON (список блоков) и Дерево (вложенная структура).

Пример Flat JSON (стиль Editor.js):

{
  "blocks": [
    {
      "id": "abc123",
      "type": "header",
      "data": {
        "text": "Заголовок",
        "level": 2
      }
    },
    {
      "id": "def456",
      "type": "paragraph",
      "data": {
        "text": "Текст параграфа"
      }
    },
    {
      "id": "ghi789",
      "type": "image",
      "data": {
        "url": "/uploads/photo.jpg",
        "caption": "Подпись"
      }
    }
  ],
  "version": "2.28.0"
}

Пример дерева (ProseMirror/Tiptap):

{
  "type": "doc",
  "content": [
    {
      "type": "heading",
      "attrs": {
        "level": 2
      },
      "content": [
        {
          "type": "text",
          "text": "Заголовок"
        }
      ]
    },
    {
      "type": "paragraph",
      "content": [
        {
          "type": "text",
          "text": "Обычный "
        },
        {
          "type": "text",
          "marks": [
            {
              "type": "bold"
            }
          ],
          "text": "жирный"
        },
        {
          "type": "text",
          "text": " текст"
        }
      ]
    }
  ]
}

В PostgreSQL данные хранятся в jsonb с GIN-индексом для полнотекстового поиска. Каждый тип блока — отдельная React-компонента с режимами просмотра и редактирования. Регистрируем блоки через плагинную систему:

interface BlockPlugin<T = Record<string, unknown>> {
  type: string;
  label: string;
  icon: React.ReactNode;
  defaultData: T;
  render: (data: T, ctx: RenderContext) => React.ReactNode;
  edit: (data: T, onChange: (data: T) => void) => React.ReactNode;
  validate?: (data: T) => ValidationError[];
  toHTML?: (data: T) => string;
}

Контекстный тулбар, slash-команды и drag-and-drop

Тулбар появляется только при выделении текста — не занимает место и не отвлекает. Реализуем плавающую панель через FloatingToolbar с кнопками жирности, курсива, ссылки.

Slash-команды — стандарт для блочных редакторов: ввод / открывает меню выбора блока. Фильтрация по названию ускоряет работу.

Drag-and-drop сортировка блоков реализована через @dnd-kit/core. Блоки перетаскиваются без потери контента.

Как работает история изменений?

class EditorHistory {
    private undoStack: EditorState[] = [];
    private redoStack: EditorState[] = [];
    private maxSize = 100;

    push(state: EditorState) {
        this.undoStack.push(structuredClone(state));
        if (this.undoStack.length > this.maxSize) this.undoStack.shift();
        this.redoStack = [];
    }

    undo(current: EditorState): EditorState | null {
        if (this.undoStack.length === 0) return null;
        this.redoStack.push(structuredClone(current));
        return this.undoStack.pop()!;
    }

    redo(current: EditorState): EditorState | null {
        if (this.redoStack.length === 0) return null;
        this.undoStack.push(structuredClone(current));
        return this.redoStack.pop()!;
    }
}

Для больших документов используем иммутабельные структуры (Immer) для экономии памяти.

Автосохранение — через дебаунс 2 секунды после последнего изменения. Статус отображается в интерфейсе: «Сохранено», «Сохранение...», «Есть изменения».

Рендеринг на фронтенде сайта

JSON редактора рендерится на публичной части сайта. Два подхода:

1. SSR через React — данные передаются в те же компоненты блоков, что и в редакторе. Идеально для Next.js.
2. Серверный рендеринг — на PHP или Node.js парсим JSON и генерируем HTML напрямую, без React.

Пример рендерера на Laravel:

class BlockRenderer {
    protected array $renderers = [];

    public function register(string $type, callable $renderer): void {
        $this->renderers[$type] = $renderer;
    }

    public function render(array $blocks): string {
        return collect($blocks)
            ->map(fn($block) => ($this->renderers[$block['type']] ?? fn() => '')($block['data']))
            ->implode("\n");
    }
}

Работа с медиа и производительность

Редактор интегрируется с медиатекой CMS. Изображения загружаются через drag-and-drop прямо в блок — прогресс-бар показывает статус. Для больших документов (сотни блоков и десятки изображений) включаем виртуализацию: рендерим только видимые блоки плюс буфер, остальные заменяем плейсхолдерами. Используем react-window или @tanstack/virtual.

Что входит в работу

• Анализ требований и проектирование модели данных
• Разработка ядра редактора и системы плагинов
• Реализация типовых и кастомных блоков
• Интеграция с CMS через REST API или прямую работу с БД
• Настройка автосохранения, истории, медиатеки
• Тестирование и отладка
• Создание документации и обучение редакторов
• Гарантийная поддержка 12 месяцев

Сроки и стоимость

Ориентировочные сроки:

• MVP: 3–4 недели
• Полноценный редактор: 8–12 недель
• Сложные проекты с уникальными блоками: до 16 недель

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

Почему выбирают нас?

• 10+ лет опыта в разработке редакторов для медиа и корпоративных сайтов
• 50+ проектов — от небольших блогов до крупных порталов
• Прозрачный процесс: каждые 2 недели демонстрируем промежуточные результаты
• Гарантия 12 месяцев и бесплатная поддержка после запуска

Закажите разработку редактора под ключ — свяжитесь с нами для консультации и получите инструмент, который полностью соответствует бизнес-задачам.