Совместное редактирование в WordPress: как работает

Совместное редактирование — возможность нескольким людям одновременно править одну запись, как в Google Docs, — должно было стать главной фичей WordPress 7.0. За две недели до релиза, 8 мая 2026 года, команда ядра убрала его из версии: тестирование выявило гонки состояний, лишнюю нагрузку на сервер и проблемы с памятью. Но технология не отменена — она развивается в плагине Gutenberg, и её уже можно потрогать. Разбираем, как всё устроено под капотом, что изменится для редакций и как подготовиться к моменту, когда фича доедет до ядра.

Какую проблему это решает

Сейчас WordPress работает по принципу «одна запись — один редактор». Если запись открыта у коллеги, вы увидите диалог блокировки: «Этот материал сейчас редактирует другой пользователь». Дальше три варианта, и все плохие: ждать, «перехватить» запись (и коллега потеряет несохранённое), или править копию в другом месте и переносить руками.

Для блога с одним автором это не проблема. Для редакции — ежедневная боль: автор пишет текст, редактор правит заголовки, SEO-специалист заполняет метаданные — и все они стоят в очереди к одной записи.

Совместное редактирование убирает очередь: запись открывают все, кто имеет право её редактировать, каждый видит, кто ещё в документе и какой блок сейчас правит, а изменения сливаются автоматически.

Как это устроено: три слоя

Архитектура, которую команда Gutenberg описала в блоге Make WordPress Core, состоит из трёх слоёв.

1. Интерфейс (Interface). То, что видит пользователь: аватарки участников в шапке редактора, индикаторы присутствия — цветные рамки вокруг блока, который сейчас правит коллега, — и переработанные сообщения вместо старого диалога блокировки.

2. Движок (Engine). Сердце системы — библиотека Yjs, реализация CRDT (conflict-free replicated data types, бесконфликтные реплицируемые типы данных). Идея CRDT: каждая правка описывается так, что правки разных людей можно применить в любом порядке — и все участники в итоге получат одинаковый документ. Не нужно спрашивать «чья версия главнее»: конфликтов в привычном смысле не возникает. Тот же подход используют Figma и Notion.

3. Транспорт (Transport). Слой доставки изменений между браузерами участников. Здесь два режима, и это самое важное для владельцев сайтов.

Polling или WebSocket: два транспорта

Критерий	HTTP-polling (по умолчанию)	WebSocket
Как работает	Редактор раз в несколько секунд опрашивает сервер: «есть новые правки?»	Постоянное двустороннее соединение: правки летят мгновенно
Задержка	Секунды	Доли секунды
Требования к хостингу	Никаких — работает на любом shared-хостинге	Сервер должен держать постоянные соединения
Нагрузка	Регулярные запросы от каждого участника	Одно соединение на участника
Кому подходит	Всем по умолчанию	Редакциям, где важна мгновенная синхронизация

Выбор HTTP-polling режимом по умолчанию — прагматичное решение: WordPress работает на миллионах дешёвых хостингов без поддержки WebSocket, и фича должна работать «из коробки» везде. Плата — задержка: правки коллеги появляются не мгновенно, а с лагом в несколько секунд.

Почему фичу вырезали из 7.0

По итогам тестирования команда назвала несколько причин: слишком большая площадь изменений в ядре, гонки состояний (race conditions), нагрузка на сервер и неэффективное использование памяти; фаззинг-тестирование продолжало выявлять баги. Решение честное: лучше перенести фичу, чем отгрузить сырую синхронизацию контента на треть интернета — цена ошибки здесь — потерянные тексты.

Что важно: инфраструктурные части, на которые опирается совместное редактирование, продолжают развиваться в ядре, а сама фича осталась в плагине Gutenberg как экспериментальная. Это обычный путь для больших возможностей WordPress — так же в своё время обкатывали и сам блочный редактор, и редактор сайта. Что при этом реально вошло в релиз — в нашем разборе WordPress 7.0: что нового.

Как попробовать уже сейчас

Понадобится тестовый сайт — локальный или staging. На боевом сайте экспериментальные функции включать не стоит.

1. Установите и активируйте плагин Gutenberg из официального каталога — это «канал разработки» редактора, где фичи появляются раньше ядра.
2. Откройте настройки экспериментов плагина (страница Gutenberg → Experiments в админке) и включите пункт, отвечающий за совместное редактирование (Collaborative editing / Real-time collaboration — название пункта меняется от версии к версии).
3. Откройте одну и ту же запись с двух разных аккаунтов — проще всего в двух браузерах или в обычном и приватном окне.
4. Проверьте сценарии: правка разных блоков одновременно, правка одного и того же абзаца, добавление и удаление блоков, поведение при обрыве соединения.

Если пункта эксперимента в вашей версии плагина нет — фичу могли временно скрыть на доработку: у экспериментальных функций это нормально. Следите за анонсами на make.wordpress.org/core.

Сценарий: редакция из трёх человек

Как изменится типичный процесс выпуска статьи — «до» и «после».

Сейчас. Автор пишет черновик и закрывает запись. Редактор открывает её, правит, оставляет замечания в стороннем таск-трекере, закрывает. Автор вносит правки — и снова по кругу. SEO-специалист ждёт финала, чтобы заполнить метаданные. Одна статья — три «очереди» и переписка в мессенджере.

С совместным редактированием. Все трое открывают запись одновременно. Автор дописывает финал, редактор в это время правит лид — каждый видит по цветной рамке, где работает коллега, и не лезет в тот же блок. SEO-специалист параллельно заполняет метаданные. Созвон на 15 минут вместо суток переписки.

Что не изменится. Права доступа работают как раньше: кто не мог редактировать запись — тот и не сможет. Ревизии сохраняются, так что откат к прежней версии остаётся страховкой (в 7.0 экран ревизий, кстати, стал визуальным). А договорённости «кто за что отвечает» всё равно нужны — технология убирает блокировку, но не заменяет редакционный процесс.

Открытые вопросы: что ещё предстоит решить

Совместное редактирование — не только слияние правок. Вокруг него есть смежные механики, судьбу которых команде ещё предстоит определить, и именно они определят, насколько удобной фича будет в бою:

• Автосохранение и черновики. Сейчас у каждой записи один автор автосохранения. Когда авторов трое, нужно решить, чьё состояние считается «текущим черновиком» и как это отражается в ревизиях.
• Совместимость с плагинами. Тысячи плагинов расширяют редактор — от SEO-панелей до кастомных блоков. Каждому придётся корректно вести себя, когда документ меняется «сам по себе» из-за правок коллеги.
• Обрывы связи. CRDT позволяет продолжить правку офлайн и слить изменения после переподключения, но пользовательские сценарии — что видит человек с нестабильным интернетом — ещё шлифуются.

Это нормальный объём работы для фичи такого масштаба — и ещё один аргумент, почему её не стали спешно заталкивать в 7.0.

Чек-лист: подготовьте редакцию заранее

Пока фича зреет в плагине Gutenberg, можно подготовиться, чтобы включить её в день появления в ядре:

• Заведите каждому участнику свой аккаунт. Совместное редактирование бессмысленно, если вся редакция сидит под одним логином «admin». Заодно это требование безопасности.
• Раздайте роли по смыслу: авторам — Author, редакторам — Editor. Индикаторы присутствия показывают конкретных людей — с общими аккаунтами это не работает.
• Проверьте хостинг на WebSocket, если нужна мгновенная синхронизация: спросите поддержку, держит ли сервер постоянные соединения. Если нет — polling всё равно будет работать.
• Опишите процесс: кто финализирует текст, кто нажимает «Опубликовать». Одновременный доступ без договорённостей — это хаос в реальном времени.
• Потренируйтесь на staging — прогоните сценарий выпуска статьи втроём и найдите узкие места до того, как переносить процесс на прод.

Вывод

Совместное редактирование — самая амбициозная фича WordPress за годы, и именно поэтому её не стали отгружать сырой. Архитектура выбрана зрелая: CRDT на Yjs, транспорт с деградацией до обычного polling на дешёвых хостингах, знакомые по Figma индикаторы присутствия. Следить за прогрессом стоит в плагине Gutenberg и в блоге Make WordPress Core, а подготовить аккаунты, роли и редакционный процесс можно уже сегодня — тогда в день, когда фича доедет до ядра, вашей редакции останется просто обновить WordPress и открыть общий документ.