Огромный сборник статей от WPTec для начинающих

Мнение

Спросите бармена: что происходит при изменении разметки блока?

Я разработчик, который недавно начал работать с Гутенбергом. Есть множество удивительных преимуществ и функций, но есть также масса недостатков, несоответствий, а также совершенно ужасная и устаревшая документация.

Одним из худших аспектов Gutenberg с точки зрения разработчика была проверка блоков. Рассмотрим следующий сценарий. Я создаю собственный (нединамический) блок на основе JavaScript, а редактор CMS добавляет этот блок на тысячи страниц. Что произойдет, когда или если мне понадобится обновить разметку блока?

По умолчанию все блоки переходят в состояние недействительности и не отражаются на интерфейсе сайта. Редактору CMS пришлось бы перейти на тысячи страниц и вручную щелкнуть кнопку, которая позволяет восстановить блок.

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

Разве у разработчиков блоков не должно быть способа отказаться от процесса проверки или глобального способа восстановления блоков?

PJ
Ты уж точно ничего не скрываешь, Пи Джей. Хотя многое из этого носит более технический характер, чем я обычно люблю рассказывать здесь, в таверне, я решил обратиться к Риаду Бенгелле, одному из ведущих разработчиков Gutenberg, чтобы получить более подробное представление о ситуации.

Прежде чем углубиться в его ответ, я немного подумал об одном аспекте вашего вопроса. Бывают случаи, когда разработчикам нужно отказаться от старой разметки и перейти к чему-то новому. Однако это не должно происходить часто. Как правило, это признак плохой архитектуры, если HTML необходимо регулярно обновлять. Это также приводит к другим проблемам, таким как третья сторона не может поддерживать стилистические изменения.

При разработке блоков или любого типа приложения, которое выводит интерфейсный код, вам нужно подумать о том, как это должно выглядеть сегодня и через 10 лет. Что произойдет, если пользователь добавит некоторый собственный CSS для стилизации вашего блока, а структура HTML блока изменится? С их точки зрения, обновление вашего блока привело к поломке их сайта. То же самое можно сказать и о другом плагине, который каким-то образом расширяет ваш плагин.

Спросите любого автора темы, насколько это неприятно, когда Gutenberg / WordPress меняет вывод блока. Несмотря на то, что за последние пару лет он улучшился, стилизация блоков для редактора и внешнего интерфейса часто была кошмаром для обслуживания.

Как разработчик, я всегда пытался продумать любые реальные последствия внесения этих изменений с точки зрения пользователя. Это должно произойти с первого дня, а не после того, как вы выпустили свой проект.

Это добавляет время раннему проекту, когда вы просто пытаетесь выпустить его и передать в руки пользователей. Вот здесь и помогает сделать шаг назад перед выпуском. Отойди от компьютера. Иди на прогулку. Подумайте об архитектуре вашего проекта и о том, идеален ли он на долгосрочную перспективу.

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

Независимо от вашего метода разработки, следование подходу проекта, основанному на пользовательском опыте, поможет в долгосрочной перспективе.

«Чтобы правильно понять проблему, нужно понимать, как блоки работают и редактируются», – сказал Бенгелла. «Экземпляры блоков представляют собой объект JSON, и пользовательский интерфейс редактора управляет этим JSON, но для обеспечения обратной совместимости, для обеспечения сохранения содержимого пользователя в наиболее читаемом формате и максимального соответствия веб-стандартам редактор блоков не хранит объект JSON, а его сериализацию в формате HTML post_content».

Эта сериализация анализируется и преобразуется в JSON, когда редактор перезагружает контент для повторного редактирования. На заключительных этапах синтаксического анализа автор блока должен решить, как сохранить и проанализировать объект.

«А теперь представьте, если бы пользователь изменил сохраненный HTML (сериализацию) и просто поместил туда любой случайный контент», – сказал Бенгелла. «Блок может быть не в состоянии правильно проанализировать HTML, потому что он не соответствует его ожиданиям (что было определено автором блока), что означает, что воссоздание этого объекта JSON для управления им будет невозможно на данном этапе. . »

Когда это происходит, редактор блоков предоставляет пользователю интерфейс для принятия обоснованного решения. Они могут попытаться «принудительно проанализировать» блок JSON или преобразовать его в HTML или классический блок.

Такой же тип аннулирования может произойти, когда разработчик плагина обновляет свой блок. Однако вместо изменения сохраненного HTML-кода разработчик изменил «ожидания» от блока, изменив способ его сохранения и анализа.

«Вот почему мы просим разработчиков блоков предоставлять устаревшие блоки, представляющие старую разметку того же блока», – сказал Бенгелла. «Об устаревании можно также думать как о допустимых альтернативных источниках для одного и того же блока. Это позволяет редактору анализировать старую разметку при загрузке и сохранять новую разметку обратно, если в блок произведено обновление ».

У WordPress есть документация по прекращению поддержки блоков . Однако это не досконально. Лучший источник увидеть реальные устаревания – это просмотреть библиотеку блоков Гутенберга . У устаревших блоков есть deprecated.jsфайл.

Бенгелла сказал, что эта система может расстраивать авторов блоков. Это особенно заметно в среде разработки при внесении изменений. Это заставило разработчиков попросить метод отключения алгоритма проверки.

«Это то, что мы не хотим предоставлять в настоящий момент, потому что, как объяснялось выше, проверка также важна, когда разметка изменяется по другой причине (внешнее редактирование, другой редактор и т. д.)», – сказал он. «Таким образом, это может привести к потере контента для пользователей, которые ничего не знают. Сейчас предпочтение отдается осведомленности пользователей ».

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

Рекомендуем прочитать
Мнение

Плагин Delete Me для WordPress помогает владельцам веб-сайтов предоставить право на забвение GDPR

Мнение

Команда Gutenberg наращивает юзабилити-тестирование в WordCamp US

Мнение

Плагин распространителя теперь в бета-версии: новое решение для синдикации контента WordPress от 10up

Мнение

Gutenberg 1.8 добавляет большую расширяемость для разработчиков плагинов

Подпишитесь на рассылку
и будьте в курсе новостей Wordpress

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *