Контрибьюторы WordPress тестируют серверный подход к реализации совместного редактирования в реальном времени (RTC)

Контрибьюторы, работающие над внедрением функции совместного редактирования в реальном времени (RTC) в WordPress, тестируют новый подход server-aware: правки будут передаваться через WordPress, а не синхронизироваться напрямую между браузерами пользователей. В настоящее время рассматриваются три возможных варианта «механизма синхронизации», и сообществу предлагается помочь в выборе того решения, которое будет развиваться дальше.

Крис Сарате, контрибьютор, спонсируемый Automattic, недавно рассказал об изменении подхода в блоге Make WordPress Core. Он сообщил, что после того, как в мае функцию RTC исключили из состава WordPress 7.0, он вместе с коллегами-инженерами из Automattic (Алеком Гитчесом, Деннисом Снеллом и другими) работал над решением проблем, которые он назвал «обоснованными опасениями».

«Мы считаем, что эти опасения требуют смены курса: процесс совместного редактирования должен учитывать особенности сервера, а контроль должен оставаться за ядром WordPress», — заявил Сарате.

В рамках эксперимента с RTC в плагине Gutenberg объединение правок пока происходит только на стороне браузера. Редактор каждого пользователя хранит собственную копию записи и обменивается обновлениями с другими участниками совместного редактирования до тех пор, пока все копии не станут идентичными; при этом изменения остаются лишь в оперативной памяти браузера, пока кто-либо не нажмет кнопку сохранения. По словам Сарате, такой подход позволил внести в ядро ​​ минимум изменений и повысить отзывчивость функции, однако оставил ряд проблем нерешенными.

По словам Сарате, первая проблема заключается в том, что сервер не может определить, кто именно написал тот или иной текст. Он проиллюстрировал этот риск примером, который назвал «отмыванием контента»:

Автор (которому запрещено публиковать необработанный HTML-код) и администратор совместно работают над одной публикацией. Автор добавляет блок, содержащий тег script, и этот блок синхронизируется с редактором администратора. Администратор, работая в другой части публикации, исправляет опечатку и нажимает кнопку «Сохранить». Публикация обновляется с правами администратора — в том числе и вместе со скриптом, на который администратор даже не обратил внимания.

Он также отметил, что обновления, внесенные через REST API или WP-CLI, не синхронизируются с данными пользователей, редактирующих контент в браузере, поэтому скрипт, записывающий изменения в запись, может стереть их работу. Кроме того, при рассинхронизации действий соавторов (например, из-за разрыва соединения) сохранение изменений одним пользователем может привести к потере правок, внесенных другим.

По словам Сарате, решением стало внедрение серверной части в этот процесс: «При каждом обновлении WordPress фиксирует, кто внес изменения, проверяет наличие у пользователя соответствующих прав, объединяет эти изменения с правками других пользователей и сохраняет итоговый результат».

Три варианта механизмов синхронизации

В своей публикации Сарате описывает три предложенных механизма синхронизации, использующих различные подходы к объединению данных на стороне сервера. Все три варианта доступны для тестирования в экспериментальном плагине на GitHub; в файле README этот плагин характеризуется как «примерный инструмент-прототип, а не готовое решение».

• Yjs-server использует PHP-реализацию Yjs — фреймворка синхронизации, лежащего в основе текущего эксперимента в редакторе Gutenberg; на сервере хранится публично доступный документ, расшариваемый в редакторах пользователей.
• Distributed Editing (DE-RTC) использует метод трехстороннего слияния, сопоставляя последнюю сохраненную версию, версию, предложенную редактором, и исходную версию, с которой начиналась работа; синхронизация происходит при сохранении или автосохранении.
• Intent log (журнал намерений) отправляет краткие описания каждого изменения (например, «переместить этот блок»); сервер сохраняет их в упорядоченном журнале, который затем может воспроизвести редактор каждого пользователя.

В конце сентября Сарате сообщил в канале #feature-realtime-collaboration в Slack-сообществе WordPress, что цель состоит в выборе одного из вариантов механизма синхронизации до конца месяца. Однако после истечения этого срока, 2 октября, он опубликовал обновление, в котором говорилось, что команда пересмотрела свои планы.

«Мы надеялись, что выбор конкретного механизма позволит нам лучше сосредоточиться на задаче и стимулирует участие сообщества. Оглядываясь назад, понимаешь, что мы действовали с точностью до наоборот! Именно контрибьюции и участие в обсуждениях — лучший путь к принятию такого решения», — отметил он.

Вместо этого Сарате сообщил, что команда сосредоточится на том, чтобы плагин было легко тестировать или внедрять в существующие установки WordPress, а также на подготовке публикации на сайте Make, где будут сравниваться различные механизмы и их особенности. В файле README плагина в качестве сопровождающих (maintainers) указаны Сарате, Гитчес и Джо Фуско  — контрибьютор, чью работу спонсирует компания WP Engine.

В следующем посте он добавил, что лучшая возможность для всех желающих внести свой вклад — это протестировать плагин, сообщить об ошибках, отправить pull-запросы или просто начать обсуждение.

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

Однако загвоздка заключается в нагрузке на сервер: именно она стала причиной проблем с масштабированием, преследовавших RTC на протяжении релиз-цикла 7.0. Сарате признал, что перенос задач на сервер приведет к увеличению этой нагрузки.

«Частый опрос требует значительных затрат ресурсов и вряд ли станет реалистичным решением для эффективного взаимодействия на хостингах с ограниченными возможностями», — написал он, добавив, что команда готова предложить альтернативные транспорты для тех хостинг-провайдеров, которые готовы выделить больше ресурсов.

Представителей хостинг-компаний призывают принять участие в тестировании. Крис Рейнольдс, старший менеджер по взаимодействию с разработчиками и контрибьютор, чью деятельность спонсирует компания Pantheon, 24 сентября опубликовал в блоге Make WordPress Hosting обращение с просьбой протестировать эти механизмы, уделив особое внимание производительности. Рейнольдс отметил, что отзывы хостинг-провайдеров «повлияют на дальнейшее развитие этой функции».

«Наше исследование находится на начальной стадии, и решение пока не готово к добавлению в ядро ​​WordPress», — написал Сарате в своей публикации на ресурсе Make. Функцию RTC намеренно не включили в дорожную карту версии WordPress 7.2; также пока не определены сроки ее возможного включения в будущие релизы WordPress.

Стоит ли включать RTC в ядро ​​WordPress?

В комментариях к публикации Сарате разработчик Ник Чоми высказал мнение, что функция совместного редактирования в реальном времени (RTC) вряд ли впишется в философию WordPress, согласно которой в ядро ​​включаются лишь те возможности, которые будут востребованы 80% пользователей или более. Чоми отметил: «Совместное редактирование принесет пользу лишь ОЧЕНЬ небольшому числу пользователей».

Сарате не стал спорить с этим утверждением применительно к человеческому совместному редактированию. «Если говорить об узком сценарии совместного редактирования с другими людьми, то я согласен с этим доводом», — написал он. Однако он подчеркнул, что лежащая в основе этой функции архитектура может принести пользу каждому юзеру WordPress, указав на такие преимущества, как более детальная история правок с возможностью выборочного восстановления, стабильные ссылки (позволяющие реализовать механизм предложений по правкам), а также возможность совместной работы людей с плагинами, запросами REST API, командами WP-CLI и ИИ-агентами.

Энн Маккарти из компании Automattic, руководившая разработкой версии WordPress 7.1, также ответила Чоми. «Этот вопрос обсуждается с самого момента появления идеи совместного редактирования в реальном времени», — написала она, добавив, что решение о включении столь масштабной функции в ядро ​​должно приниматься руководством с учетом отзывов пользователей, данных от хостинг-провайдеров и архитектурных соображений.

Желающие принять участие в тестировании могут установить плагин из репозитория gutenberg-sync-engines на GitHub и поделиться своими отзывами в канале #feature-realtime-collaboration в Slack-сообществе WordPress или в комментариях к публикации Сарате на сайте Make WordPress.

Источник: oddstyle.ru