Ключевые понятия

Блоки

Блоки — это абстрактная единица для организации и составления контента, объединенная для создания контента для веб-страницы.

Блоки являются иерархическими, так блок может быть дочерним или родительским для другого блока. Одним примером является столбец с двумя столбцами, который может быть родительским блоком для нескольких дочерних блоков в каждом столбце.

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

<!-- wp:paragraph {"key": "value"} -->
<p>Welcome to the world of blocks.</p>
<!-- /wp:paragraph -->

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

Каждый блок содержит атрибуты или параметры конфигурации, которые могут быть получены из необработанного HTML-содержимого, с помощью мета или других настраиваемых источников.

Абзац является блоком по умолчанию. Вместо новой строки после ввода return на клавиатуре, попробуйте думать о ней как о пустом блоке абзаца (введите /, чтобы вызвать автозаполнение Slash Inserter — / image вызовет изображения, а также вставки из Instagram).

Пользователи вставляют новые блоки, нажимая кнопку «плюс» для «Вставки блока», вводя / для «
Slash Inserter » или «return» для пустого блока абзаца.

Блоки могут быть продублированы внутри контента с помощью меню на панели инструментов блока или с помощью сочетания клавиш.

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

Блоки могут быть ограничены или заблокированы на месте с помощью шаблонов и пользовательского кода.

Категории блоков

В Block Inserter, который отображает доступные для пользователя блоки сайта, каждый заголовок аккордеона представляет собой категорию блоков, которые являются значениями по умолчанию или настраиваются разработчиками с помощью плагинов или кода.

Многоразовые блоки

Многоразовые блоки — это способ поделиться блоком (или несколькими блоками) как многократно повторяемым фрагментом контента.

Любые изменения в повторно используемом блоке производятся для каждого использования повторяемого блока.

Многократно используемые блоки хранятся как скрытый тип записи и являются динамическими блоками, которые ссылаются на post_id и возвращают post_content для этого wp_block.

Шаблоны

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

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

Содержимое в WordPress хранится в виде текста в формате HTML post_content. HTML — это надежный формат разметки документов, который используется для описания содержимого, такого же простого, как неформатированные абзацы текста, и сложного, как целые интерфейсы приложения. Понимание HTML не является тривиальным; значительное количество существующих документов и инструментов имеют дело с технически неверным или неоднозначным кодом. Этот код, даже когда он действителен, может быть невероятно сложным и сложным для анализа и понимания.

Главное — позволить машинам работать на том, что у них хорошо получается, и оптимизировать работу для пользователя и документа. Аналогия с печатным прессом может быть продолжена в том, что важна печатная страница, а не расположение металла, которое ее породило. На самом деле, расположение типов — довольно неудобный механизм хранения. Страница — это и результат, и правильный способ хранения данных. Тип металла — это просто инструмент для публикации и редактирования, но более эфемерный по своей природе. Точно так же, как мы используем дерево объектов (например, JSON) в редакторе. У нас есть возможность перестроить эту структуру из напечатанной страницы, как если бы мы печатали нотации на полях, что позволяет машине знать, какие сорта (тип металла) собирать для воссоздания страницы.

Блоки более высокого уровня, чем HTML

Блоки — это полезный инструмент для описания того, как редактировать контент, выходящий за рамки простого текста, но он не несет особого смысла после того, как итоговая страница сгенерирована и используется в виде HTML-документа. Несмотря на то, что конечным результатом является HTML в браузере, «блок» имеет больше значения, чем HTML, который он генерирует. Именно это дополнительное значение обеспечивает богатый опыт редактирования, поскольку позволяет приложению включать инструменты, помогающие пользователю создавать контент, который он хочет. HTML дополнен инструментами редактирования. Для многих блоков созданный HTML-код является случайным и может быть изменен. Блоки могут быть мощными и значительно более сложными, чем HTML, который они создают.

Проблема, с которой сталкивается редактор, подобный Gutenberg, состоит в том, что после того, как все было преобразовано в HTML, в разметке HTML больше не возникает никакого смысла, из которого можно создать конкретный интерфейс блока. Это означает, что содержимое HTML может быть неоднозначным: одна и та же разметка может соответствовать совершенно разным блокам. Одним из следствий этого факта является то, что он демонстрирует, как мы потеряли смысл, когда переходим к одному HTML. Таким образом, должен существовать надежный способ узнать тип блока без необходимости понимания HTML.

Кроме того, как мы узнаем, что это пришло из нашего редактора? Может быть, кто-то сунул его вручную, когда попытался быстро зайти и сменить страницу. Структура значения более высокого уровня неявна и неотличима от той же самой разметки при вводе вручную. Когда Gutenberg работает с блоком, он знает его тип и атрибуты без проверки источника HTML.

Двойственность записи

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

Пост Гутенберга — это не тот артефакт, который он производит, а именно post_content. Последняя — это печатная страница, оптимизированная для читателя, но сохраняющая невидимые отметки для последующего редактирования.

Последующие разделы этого документа будут относиться к посту Гутенберга и к блокам . Предполагается, что они не являются post_content или невидимыми отметками.

Дерево блоков

Во время выполнения блоки хранятся в памяти. Таким образом, пост Gutenberg — это не HTML, а дерево объектов и связанных атрибутов. Gutenberg опирается на модель данных, сохраняющую структуру, поэтому редакторы и представления для определенных типов блоков могут оставаться независимыми от окончательно отрисованного HTML. Это дерево, похожее на то, как HTML это дерево, хотя на верхнем уровне это просто список узлов — ему не нужен «корневой узел».

Дерево объектов описывает список блоков, из которых состоит пост.

[
    {
        type: "core/cover-image",
        attributes: {
            url: "my-hero.jpg",
            align: "full",
            hasParallax: false,
            hasBackgroundDim: true
        },
        children: ["Gutenberg posts aren't HTML"]
    },
    {
        type: "core/paragraph",
        children: ["Lately I've been hearing plen…"]
    }
];

Сериализация и цель комментариев HTML

Модель данных Gutenberg, однако, хранится в памяти при редактировании поста. Это не видно для просмотра страницы при визуализации. Как печатная страница не имеет следов структуры писем, которые ее создали в прессе.

Поскольку вся экосистема WordPress ожидает получения HTML-кода при рендеринге или редактировании публикации, Gutenberg превращает свою модель данных в нечто, что можно сохранить с post_contentпомощью сериализации. Это гарантирует, что существует единый источник для контента, и что этот источник остается читаемым и совместимым со всеми инструментами, которые взаимодействуют с контентом WordPress в настоящее время. Если бы мы хранили дерево объектов отдельно, мы столкнулись бы с риском остановки синхронизации post_contentи дерева и проблемой дублирования данных в обоих местах.

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

Это одна сторона процесса. Другая состоит в том, чтобы воссоздать внутреннее дерево данных коллекции блоков каждый раз, когда публикация должна быть отредактирована снова. Формальная грамматика определяет способ загрузки сериализованного представления поста
Gutenberg так же, как некоторые основные правила определяют, как превратить дерево в HTML-подобную строку. Посты Gutenberg не предназначены для редактирования вручную; они не предназначены для редактирования в виде документов HTML, потому что записи Gutenberg по сути не являются HTML.

Между прочим, они просто хранятся внутри post_content таким образом, что не требуют преобразования, чтобы их можно было просматривать любой устаревшей системой. Это правда, что загрузка хранимого HTML-кода в браузер без соответствующего механизма может ухудшиться, если он включает динамические блоки контента: динамические элементы могут не загружаться, генерируемый сервером контент может не отображаться, интерактивный контент может оставаться статическим. Тем не менее, он по крайней мере защищает от просмотра постов
Gutenberg в темах и установках, которые не знают Gutenberg , и обеспечивает наиболее полный доступ к контенту.

Разделители и грамматика парсинга

Вместо этого мы решили попытаться найти способ сохранить формальность, явность и недвусмысленность в существующем синтаксисе HTML. В HTML есть несколько вариантов:

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

Уникальным для комментариев является то, что они не могут законно существовать в неоднозначных местах, таких как атрибуты HTML, такие как <img alt='data-id="14"'>. Комментарии также вполне терпимы. В то время как HTML-атрибуты сложны для правильного анализа, комментарии довольно легко описываются первым <!--символом, за которым следует все, кроме -- до первого -->. Эта простота и вседозволенность означают, что анализатор может быть реализован несколькими способами без необходимости правильно понимать HTML, и мы можем использовать более удобный синтаксис внутри комментария — нам нужно только избегать последовательностей с двойным дефисом. Мы используем это для хранения блочных атрибутов: литералов JSON внутри комментария.

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

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

NB . Определяющим аспектом блоков являются их семантика и механизм изоляции, который они предоставляют; другими словами, их идентификация. С другой стороны, где хранятся их данные, это более либеральный аспект. Блоки поддерживают не только статические локальные данные (через литералы JSON внутри HTML-комментария или внутри HTML-кода блока), и ожидается, что появятся дополнительные механизмы ( например , глобальные блоки или другие способы хранения в дополнительных WP_Postобъектах). Смотрите атрибуты для деталей.

Анатомия сериализованного блока

Когда блоки сохраняются в контенте, после сеанса редактирования, его атрибуты — в зависимости от природы блока — сериализуются в явные комментарии разделители .

<!-- wp:image -->
<figure class="wp-block-image"><img src="source.jpg" alt="" /></figure>
<!-- /wp:image -->

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

<!-- wp:latest-posts {"postsToShow":4,"displayPostDate":true} /-->

Жизненный цикл Gutenberg

Таким образом, рабочий процесс для редактирования поста Gutenberg начинается с получения сохраненной версии документа и создания дерева в памяти, сопровождаемого наличием разделителей токенов. Он заканчивается обратным: сериализация блоков в post_content. Во время редактирования все манипуляции происходят внутри дерева блоков. Итак, пост Gutenberg построен на структуре данных в памяти, которая каким-то образом сохраняется полностью изоморфным образом. Прямо сейчас это постоянство осуществляется с помощью пары сериализации / синтаксического анализатора, но его можно также легко заменить с помощью плагина для хранения структуры данных в виде BLOB-объекта JSON где-то еще.