Yandex YML — Drupal модуль для генерации Yandex Market Language файла

Аватар пользователя Niklan
4

Привет. На прошлой неделе появилась задача сделать генерацию YML (Yandex Market Language, не путайте с YAML, у них одинаковые расширения, но разные назначения) на Drupal 8, модулей я под это дело не нашел. Был один заточенный под уберкарт, но он вроде как заброшен, и мне надо генерировать для начала вовсе из нод и любых других источников, вот я и написал соответствующий модуль.

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

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

Ссылки: drupal.org, github, документация

Модули и темы:
Тип материала:
Версия Drupal:

Комментарии

Аватар пользователя itcrowd72
itcrowd72 9 месяцев назад

Спасибо! На главную бы

Аватар пользователя gun_dose
gun_dose 9 месяцев назад
1

Крутая вещь. Возможно, позже пригодится. Но хотел бы обратить внимание на один момент - для загрузки в яндекс маркет необходимо, чтобы поле атрикул содержало только буквы и цифры. Но на деле зачастую в артикулах есть и точки, и дефисы, и пробелы, и вообще непонятно что. Валидировать на этот предмет артикулы во время создания товаров - не вариант, особенно для тех, кто торгует по сторонним прайсам. Помню как-то решал проблему по-простому - выпиливал все эти символы из артикула. Но в результате артикул может стать неуникальным. Возможно, нужен какой-то дополнительный сервис для валидации и маппинга артикулов, чтобы запоминать, что 123-456 соответствует в YML значению 123456, а 123.456, скажем 1234560.

В общем, вот такой Feature Request :)

Аватар пользователя Niklan
Niklan 9 месяцев назад

Интересный кейс. Я просто впервые делал файл под 7-ку, потом, учитывая что все новые сайты на 8-ке, желание появилось и у них, модуль сделал, а вот граблей ещё не наловил.

Надо будет подумать на счёт этого. Валидировать в любом случае нужно. Ведь если скормить не валидный артикул то и Яндекс его не примет, какой смысл в таком оффере если он не проходит валидацию, и, вероятнее всего, просто будет исключен? Либо, как вариант, вообще валидаторы не писать, ибо валидатор есть онлайн, в принципе, пусть каждый что хочет делает, а уже Яндекс ткнет что не так.

Ну а вообще можно в принципе какой-нибудь подмодуль сделать где бы создавалась табличка: сущность, id, оригинальное значение, обработанное значение и так не будет дублей.

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

Аватар пользователя gun_dose
gun_dose 9 месяцев назад

Есть такое понятие, как заводской артикул. Во многих сферах предпочтительно использовать именно его - это облегчает работу и контентщика, и продавца, и покупателя. Плюс многие торгуют по прайсам поставщиков, а поставщики тоже берут артикулы производителя. Если в магазине очень много товаров, то бывает, их грузят из 5 и более различных прайсов. Загрузка используется для обновления цен и остатков. Именно по этой причине SKU в Product Variation должен совпадать с артикулом из прайса. И именно поэтому я рассматриваю в качестве решения проблемы яндекс-маркета выгрузку в маркет под другими (форматированными) артикулами.

Niklan написал:
Ну а вообще можно в принципе какой-нибудь подмодуль сделать где бы создавалась табличка: сущность, id, оригинальное значение, обработанное значение и так не будет дублей.

Мне тоже кажется, что это оптимальный вариант.