Редактируемые продавцом страницы кофе на metafields Shopify

Представьте покупателя, который сравнивает два кофе одного происхождения. Дело не в цене. Он читает происхождение, обработку, высоту произрастания, профиль обжарки и вкусовые ноты и решает, с какой чашкой хочет просыпаться. У универсальной коммерческой темы нет понятия об этих атрибутах спешелти-кофе. Она даёт базовые примитивы коммерции, но поля, специфичные для кофе, всё равно нужно спроектировать и подключить к продукту.

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

Этот разбор дополняет кейс Boxwood Coffee. Вот как были смоделированы данные.

Два вида информации

Первым решением было перестать относиться к «информации о продукте» как к чему-то единому. У кофейного продукта её на самом деле два вида, и разделяет их один вопрос: меняет ли эта информация корзину или помогает принять решение?

Выбор при покупке

Помол и вес. Они меняют то, что попадает в корзину, цену и остаток на складе.

Описательные атрибуты

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

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

Варианты остаются вариантами, атрибуты становятся metafields

Помол и вес остались нативными вариантами Shopify. Именно этим они и являются, а нативная форма продукта, корзина и checkout уже надёжно с ними работают. Я стилизовал селекторы вариантов под бренд, а поведение не трогал.

Описательные атрибуты я хранил в product metafields, чтобы они жили вместе с продуктом в Shopify, а не внутри вёрстки темы. Их сгруппировали в четыре переиспользуемые Sections для страницы продукта.

Данные о кофе

Читает: происхождение, регион, высоту, сорт, обработку, профиль обжарки

Отрисовывает: структурированную сетку характеристик

Вкусовая нота

Читает: вкусовую ноту

Отрисовывает: заметную строку вкуса

История происхождения

Читает: изображение и текст истории

Отрисовывает: изображение и короткий рассказ о продукте

Информация о продукте

Читает: рекомендации по завариванию, детали обжарки и доставки, хранение и информацию о подписке

Отрисовывает: сворачиваемые практические рекомендации

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

Sections читают данные, а не хранят их

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

01 · Читать из продукта

Section берёт metafield у текущего продукта и отрисовывает его; контент не вписывается в саму Section. Именно это позволяет одной Section обслуживать любой кофе в каталоге.

02 · Аккуратно переходить к запасному значению

Каждое поле сначала проверяет product metafield, затем настройку Section, поэтому продукт, который ещё не заполнили, всё равно выглядит правильно в редакторе темы и никогда не отрисовывает пустую подпись.

Упрощённый паттерн на Liquid. Имена полей и поток управления упрощены для читаемости.

{%- liquid
  assign brewing = product.metafields.custom.brewing_recommendations.value
  assign brewing_title = product.metafields.custom.brewing_title.value
    | default: section.settings.brewing_title
-%}
{%- if brewing != blank -%}
  {% render 'accordion', title: brewing_title, content: brewing %}
{%- endif -%}

03 · Отрисовывать только при наличии данных

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

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

Одного template недостаточно

Не каждый продукт это пачка кофе. Продукту-подписке и предзаказу нужна другая страница, чем лоту одного происхождения. Вместо того чтобы копить условия по типу продукта внутри одного всё более сложного template, магазин использует отдельные product templates, назначаемые каждому продукту в админке.

• Продукт-кофе → полные Sections с данными о кофе
• Продукт-подписка → облегчённая вёрстка подписки
• Продукт-предзаказ → отдельная вёрстка предзаказа

Назначение template это выпадающий список в админке продукта, так что команда мерчандайзинга управляет тем, какую вёрстку получит продукт, без изменения кода. Описательные Sections назначены только соответствующим product templates, что не даёт им отрисовываться на несвязанных типах продуктов.

Что на самом деле получает продавец

Результат это рабочий процесс, а не функция. Чтобы запустить новый сезонный кофе, команда Boxwood:

1. создаёт продукт
2. добавляет варианты помола и веса
3. заполняет кофейные metafields (происхождение, обработка, обжарка, вкусовые ноты, заваривание и так далее)
4. назначает подходящий template и коллекцию
5. публикует

Это обычный путь запуска. Когда новый релиз укладывается в существующие Sections и metafields, изменение кода темы не требуется. Лимитированный релиз и круглогодичный бленд используют ровно те же Sections и корректно отрисовываются на своих собственных данных. Поля, оставленные пустыми, просто не появляются. Рутинные сезонные релизы стали контентным рабочим процессом, а не повторяющейся инженерной задачей.

Где проходит граница

Эта модель честна насчёт своих ограничений, и я лучше назову их, чем стану приукрашивать.

Добавить совершенно новый вид атрибута, скажем поле «диапазон высот», которого раньше не было, силами продавца не получится. Это значит добавить поле в Section и определить metafield, а это работа разработчика. Ежедневный контент и новые релизы кофе, которые укладываются в существующую модель, продавец делает сам. Изменение формы модели делается осознанно и проходит ревью.

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

Вывод

Разделяйте информацию о продукте одним вопросом: меняет ли она корзину или помогает принять решение? Выбор при покупке относится к вариантам. Описательные атрибуты относятся к metafields, рядом с продуктом, где их отрисовывают переиспользуемые Sections, которые читают данные и скрываются, когда данных нет.

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