Почему штатный Quill-редактор в CMS ломает контент
Штатный Quill-редактор в CMS ломается предсказуемо: контент-менеджер вставляет текст из Word, сохраняет — и на странице пропадают заголовки, слипаются абзацы, а таблица превращается в набор строк. Причина не в редакторе, а в том, что между полем ввода и хранилищем нет слоя, который приводит разметку к единому виду. Quill отдаёт содержимое в формате Delta — плоском списке операций вставки и форматирования, — а CMS ждёт HTML. Если преобразование делают «на глаз», каждый нестандартный случай теряет форматирование при сохранении.
Дороже всего обходится вставка из Word в редактор. Word приносит инлайновые стили, вложенные <span>, невидимые символы и собственные классы. Штатный обработчик вставки часть вырезает, часть пропускает как есть — и в базу уходит разметка, которую потом не отрендерить одинаково в браузере и в мобильном приложении. Таблицы рвутся на отдельные абзацы, списки теряют вложенность, ссылки остаются с параметрами отслеживания.
Отдельная статья потерь — SEO-разметка. Заголовки уровней подменяются жирным текстом, <h2> и <h3> исчезают из структуры, изображения приходят без alt и с исходными именами файлов. Поисковик видит плоскую страницу без иерархии, а редактор контента для сайта превращается в источник ручной правки после каждой публикации. Проблемы кастомного редактора здесь не в интерфейсе — в отсутствии валидации на входе и нормализации на выходе.
Мы разбираем, как это закрывается: схема хранения, правила преобразования Delta в HTML и обратно, загрузка медиа и защита от «грязной» вставки.
Что даёт кастомная интеграция редактора: форматы и загрузка
Структура документа вместо «сырого» HTML
Штатная вставка картинок в редактор отдаёт <img> с абсолютным адресом и инлайновыми стилями — при смене домена или CDN половина материалов «слепнет», а вёрстка плывёт на другом шаблоне. Кастомные форматы quill описываются как отдельные узлы модели документа, поэтому заголовок, врезка или таблица остаются типизированными блоками, а не набором тегов. На выходе — предсказуемая вёрстка на любом шаблоне и корректный перенос материала между разделами CMS.
Загрузка медиа без «тяжёлых» страниц
Загрузка изображений в редактор идёт через собственный обработчик: файл уходит на сервер, проверяется по типу и размеру, сжимается и получает несколько размеров под разные блоки страницы. Редактор вставляет готовый объект с набором вариантов, а не оригинал на десяток мегабайт. Страница отдаёт нужный размер под конкретное место — время загрузки и вес страницы перестают зависеть от того, кто и как загрузил картинку.
Формат Delta как единый источник
Формат delta хранит документ как последовательность операций, а не как готовую разметку. Это даёт две вещи: полную историю правок с возможностью отката и одинаковый результат при выводе в веб, письмо или мобильное приложение. Хранение контента сводится к одной структуре — рендер в HTML, plain text или PDF собирается на стороне сервиса, без ручного дублирования.
Интеграция редактора с CMS
Интеграция редактора с CMS строится так, что редактор — это поле ввода, а вся логика форматов, загрузки и валидации живёт в сервисе. Смена шаблона или фронтенд-фреймворка не ломает уже сохранённые материалы: структура документа остаётся неизменной.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Готовый плагин из маркетплейса | Простой текст, один шаблон вывода | Свои форматы и медиа-логику не расширить |
| Редактор «как есть» + ручной HTML | Разовые лендинги | Вёрстка ломается при смене шаблона, правки не отслеживаются |
| Кастомная интеграция с Delta | Мультишаблонный вывод, история правок, медиа | Требует сервисного слоя и поддержки |
Quill выбран как основа: его модель документа расширяется без переписывания ядра, а формат хранения не привязан к конкретному шаблону вывода.
Этапы внедрения кастомного редактора в CMS
Внедрение редактора в CMS — это не замена одного поля на другое, а работа с форматом хранения контента, загрузкой медиа и правами доступа. Ниже — как мы ведём такую задачу, чтобы после сдачи редактор не пришлось переписывать.
- Аудит редактора. Смотрим, что стоит сейчас, в каком виде хранится разметка (HTML, Delta, собственный формат), какие поля и шаблоны её читают. Фиксируем, где контент теряет структуру при сохранении и повторном открытии.
- Проектирование схемы. Определяем, что редактор отдаёт наружу и что принимает обратно, как конвертируются старые записи, где проходит граница между хранимым и отображаемым представлением. Схема согласуется до кода — иначе миграция превращается в переписывание.
- Настройка форматов. Собираем панель под реальные задачи: заголовки, списки, таблицы, вставки кода, ссылки. Лишние кнопки убираем — каждая лишняя тянет за собой правило очистки при вставке из внешних источников.
- Настройка загрузки медиа. Изображения и файлы идут через собственный обработчик: проверка типа и размера, переименование, привязка к записи. Отдельно проверяем вставку из буфера и перетаскивание — это самые частые источники «битых» путей.
- Проверка форматов. Прогоняем контент по кругу: создание, сохранение, повторное открытие, правка, публикация. Сверяем, что разметка не накапливает мусор после нескольких циклов редактирования.
- Перенос старых записей. Конвертируем существующий контент и проверяем выборкой: где структура не восстановилась — правим правила, а не отдельные записи вручную.
- Передача документации. Отдаём описание формата, схему конвертации, настройки загрузчика и инструкцию для редакторов контента. Дальше команда заказчика ведёт редактор сама.
Каждый этап заканчивается проверяемым результатом: схема, работающий загрузчик, прогнанный контент. Опишите вашу CMS и текущий редактор — вернёмся с оценкой и планом по этим шагам.
Чем отличается Delta-формат от HTML при хранении контента?
Delta-формат хранит документ как последовательность операций: «вставить текст», «сохранить атрибут», «удалить диапазон». Это не разметка, а журнал изменений — редактор и CMS работают с одной и той же структурой документа, поэтому при загрузке в quill редактор не нужно разбирать HTML обратно в модель. HTML-хранение контента устроено иначе: в базе лежит готовая разметка, и редактор при открытии разбирает её своим парсером, теряя то, что не описано в его схеме.
Разница проявляется на операциях, где важна точность. Delta фиксирует позицию и длину вставки, поэтому совместное редактирование и отмена действий работают предсказуемо: две правки не конфликтуют из-за разного порядка тегов. При HTML хранении контента такие конфликты приходится решать сравнением деревьев, а вложенные списки, таблицы и кастомные блоки после сериализации часто меняют структуру. Сравнение форматов здесь не про «лучше или хуже», а про то, кто отвечает за целостность — редактор или база.
У Delta есть цена. Формат нечитаем глазами: чтобы увидеть текст, нужен рендерер, а поиск по нему в базе требует отдельного индекса. HTML можно отдать напрямую в шаблон, отфильтровать санитайзером и положить в кэш — для простой редакции это дешевле в поддержке. Поэтому выбор зависит от сценария: если контент правят несколько авторов одновременно или нужны точные откаты, структура документа в Delta окупается; если публикации редкие и важна скорость выдачи, HTML проще.
На практике мы чаще делаем гибрид: Delta как источник правды для редактора и CMS, а HTML — как производный слой, который пересобирается при сохранении и отдаётся посетителям. Так редактор и CMS не расходятся в представлении документа, а фронтенд получает готовую разметку без рендера на лету.
Кейс: как мы устранили потери форматирования в редакторе
Редакция клиента — интернет-магазин с каталогом на несколько тысяч карточек — работала в стандартной сборке редактора внутри CMS. При вставке текста из Word и Google Docs терялись списки, таблицы и вложенные заголовки: разметка «схлопывалась» в один абзац, а сохранение большой статьи с десятком изображений занимало до минуты и иногда падало с ошибкой. Контент-менеджеры перепроверяли каждую публикацию вручную, а часть материалов уходила на повторную правку уже после выхода на сайт.
Что изменили
Мы разобрали цепочку от ввода до записи в базу и нашли два узких места. Первое — редактор отдавал разметку в собственном внутреннем формате, а конвертация в HTML происходила на стороне сервера «на лету», из-за чего часть узлов терялась. Второе — изображения загружались синхронно, блокируя интерфейс до завершения записи файла.
Мы перевели хранение на канонический формат разметки самого редактора: он сохраняется в базу как есть, а HTML собирается из него детерминированно — один и тот же документ всегда даёт один и тот же результат. Загрузку изображений вынесли в отдельный поток с постановкой в очередь и предпросмотром: автор видит картинку сразу, а запись идёт фоном. Дополнительно закрыли вставку из внешних источников — очистка разметки теперь сохраняет списки, таблицы и заголовки, отбрасывая только мусорные стили.
Метрики до и после
| Показатель | До | После |
|---|---|---|
| Доля публикаций с потерей форматирования | ~30% | менее 1% |
| Среднее время сохранения статьи с изображениями | до 60 сек | 3-5 сек |
| Ручные правки после публикации | 2-3 на материал | единичные случаи |
| Повторная вставка текста из Word | требовала чистки вручную | проходит автоматически |
Отдельно отметим эффект на редакцию: время на подготовку материала сократилось примерно вдвое, потому что исчезла обязательная вычитка разметки. Контент-менеджеры перестали держать в голове «правила безопасной вставки» — редактор сам приводит вставленный фрагмент к корректному виду.
Quill мы выбрали как основу именно из-за предсказуемой модели документа: разметка описывается деревом операций, а не строкой HTML, поэтому её можно надёжно сравнивать, хранить и восстанавливать. Это и дало ту самую сохранность контента, которой не хватало на старой сборке.
Сомнения перед внедрением: совместимость, миграция, откат
Самый частый технический вопрос — что будет с уже накопленным контентом. Quill хранит разметку не в HTML, а в Delta: плоском списке операций вставки и форматирования. При миграции мы конвертируем старые материалы в Delta и обратно, прогоняя каждый документ через проверку на потерю форматирования — таблицы, вложенные списки и кастомные блоки переносятся отдельным правилом, а не «на глазок». Совместимость редактора с текущей CMS проверяется на копии базы до правок в проде.
Что если понадобится откат? Конфигурация редактора и правила конвертации лежат в системе контроля версий, поэтому возврат к предыдущему состоянию — это переключение на прошлую сборку, а не ручная правка. Как быть с доступами? Роли на чтение, редактирование и публикацию разводятся на уровне CMS: автор видит только свои документы, редактор — очередь на согласование, администратор — историю изменений.
Сломается ли текущая вёрстка после подключения редактора?
Нет. Редактор подключается как отдельный модуль с изолированными стилями, поэтому темы и шаблоны сайта не затрагиваются. Мы прогоняем регресс на типовых страницах и сверяем разметку до и после — расхождения видны до выката в прод.
На руки после внедрения команда передаёт:
- конфигурацию редактора с описанием панели инструментов и правил форматирования;
- схему конвертации Delta ↔ HTML с примерами сложных документов;
- политику ролей и доступов, привязанную к группам в CMS;
- скрипты миграции контента и отчёты о проверке переноса;
- регламент отката с точками возврата на каждом этапе;
- документацию по редактору: подключение, расширение, типовые ошибки.
Опишите вашу задачу — какой контент уже накоплен, какая CMS используется и какие роли нужны. Вернёмся с оценкой и планом внедрения.
Сроки внедрения кастомного редактора: этапы и ориентиры
Сроки зависят не от самого редактора, а от того, сколько форматов, интеграций и сценариев вставки нужно закрыть. Ниже — ориентиры для типового проекта: кастомный редактор на базе Quill, встроенный в CMS, с загрузкой файлов и хранением контента в Delta-формате.
Диапазон по этапам — от трёх до семи недель на один редактор. Разброс определяется числом нестандартных сценариев: вставка из таблиц и документов, совместное редактирование, версионирование, ограничения по ролям. Каждый такой сценарий добавляет отдельную ветку проверок и заметно двигает срок.
Этапы идут не строго последовательно. Прототип и проработка хранения часто пересекаются: пока настраиваются схемы, уже понятно, в каком виде контент ляжет в базу. Это сокращает общий график, но требует, чтобы решения по формату хранения принимались на первой неделе, а не в конце.
Ориентиры выше — для команды, которая уже работала с Delta-форматом и кастомными сборками. Если контент переносится из старого редактора, добавляется этап миграции: разбор разметки, конвертация, проверка на выборке страниц.
