Разработка сайта my7days

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

А также нужен межнациональный ресурс с дополнительной логикой по показу контактов в шапке в зависимости от континента (для Америки - свой телефон, для всех остальных - итальянский номер).

В условиях сохранения CMS Битрикс, было разработано решение для каждой страны, закуплены домены, настроены сервера и разработаны механизмы вывода контента. А также введены для проекта разделенные свойства и параметры сайтов, например свое навзвание компании (ООО, LLC, Ltd), свои ленты инстаграмма, свои соц.сети, свои каталоги, свои данные по оплатам, доставкам и, свои периоды событий (новый год, черная пятница, 8 марта, каникулы). Где-то отключена возможность покупки, и оставлен просто каталог, для подачи на сертификацию.

Почти у каждой страны есть особенности по разработке ресурса. Так например у Казахстана прописано в законодательстве, чтобы ресурсы в зоне .kz хостились только у хостеров Казахстана с их IP. Что в условиях одного ядра оказалось неудобно. Поэтому была осуществлена схема, по которой можно было соединить машину со всеми сайтами с хостингом в Казахстане, сохранив при этом домен и IP на территории Казахстана. У Украины, Нидерландов нужен торговый знак на территории страны, без него нельзя регистрировать домен.

В условиях работы с Битрикс и использование многосайтовости - использование модуля sale осталась на всех ресурсах. Что потянуло за собой изменение верстки для компонента оформления заказа, добавление ему переводов, изменение стилей и логики.

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

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

Само решение получилось более менее актуальным. Именования территориальных и административных единиц на всех сайтах остались с одним переводом. Т.е. везде будет один язык.

Для проекта были разработаны несколько модулей, но есть 2 основных, даже после последнего обновления их 3 (добавился модуль с REST). Но речь пойдет о структуре деления проекта на два пространства. Пространство, относящееся непосредственно к текущему проекту, и, пространство с классами и методами, которые универсальные, и которые можно выделить в библиотеку, чтобы в последствии можно было использовать в других проектах.

В настройки проекта вошли настройки как глобальные, так и по каждому сайту. К сожалению, из-за того что вендор не до конца предусмотрел в UI использование у модуля полей, которые могут относиться к нескольким сайтам (проблема заключается в том, что если option'у дать возможность простановке сайта, и если это поле какой-нибудь checkbox, тогда на странице с выводом поля будут выведена возможность выбора значения и выбора сайта, но эта привязка будет только к основному полю (потому что привязано по id)). Из-за этого пришлось делить поля на вкладки и давать ключи к значениям с привязкой к сайту, что соответственно сподвигло на написание своего класса по вытаскиванию значения из мультисайтовых свойств.

Возможно в будущем проблему исправят, но пока до сих пор не исправлено.

В библиотеку классов вошли классы по работе с каталогом товаров, с местоположениями, с инфоблоками, с хайлоадблоками, с изображениями (рейсайз, сжатие, перегон в webp), с интеграциями, с меню, с заказами, с разметкой schema.org, с контентом (оглавление, шорткоды), с файлами, с вебформами, с тегами, с сайтами.

А также вспомогательные функции по работе с массивами (сортировка, адаптация), со строками (конвертации) и другие полезные вещи, с которыми можно столкнуться.

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

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

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

Также есть возможность указать "Наличие" товара по ссылк, и "Основной редирект", который как раз влияет на механизм редиректа пришедших из соц.сетей. Если отмечена опция, то переходить будет по той ссылке, что отмечена.

Суть редиректов - перекидывать трафик с соц.сетей в маркетплейсы. Поскольку соц.сети в основном обязывают вести на свой ресурс, а задача стоит переадресовывать пользователей, то нужно отслеживать то к чему можно будет привязаться, дабы определить откуда пришел пользователь И только по тем ссылкам, которые содержат в себе метки. В данном случае если это instagram, то utm_medium - будет содержать social, а utm_source - IGShopping, а если это pinterest - utm_source = Pinterest, utm_medium = Social. 

Если звезды сошлись (есть все нужные метки и есть забитая в элемент ссылка), то переадресовываем пользователя по ссылке с основным редиректом.

На проекте со временем пришлось вводить алгоритм очищения неиспользуемых файлов и сброса кеша для конкретных инфоблоков. Вдовесок пришлось реализовывать алгоритм удаления неиспользуемых файлов формата webp.

Реализация алгоритма по очистке неиспользуемых файлов добавлен в cron. Подразумевается проход по таблице b_file, и если файла нет в записях - он будет очищен, параллельно идет проверка на webp вариант, который может лежать в этой же папке. К нему применяется та же логика.

А вот алгоритм очистки кеша имеет свою логику. И механизм срабатывает на агентах, уже внутри системы. Все вынесено в модуль, чтобы можно было использовать в других проектах. Логика работы такова, что при изменении даты активности (дата начала/дата окончания) пометка с ID, IBLOCK_ID и датой заносится в базу. По таким записям будет проверяться когда нужно будет очищать кеш текущего инфоблока.

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

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

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

Для рекламных целей понадобилось реализовать механизм создания лендингов для наборов товара. Механизм представляет из себя инфоблок, привязанный к сайту. В элементы этого инфоблока могут быть занесены страницы - лендинги. Каждый лендинг включает в себя список товаров, символьный код, который будет участвовать в формировании ссылки на страницу, и графический контент (баннеры). Также есть возможность указать класс для <body>, сделано с целью того чтобы странице можно было бы задавать тему непосредственно для этого лендинга.

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

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

Глобальные области

/bitrix/templates/main/include/seo/

• addAfterStartBody.php - после <body>
• addBeforeEndBody.php - до </body>
• addInHead.php - между <head> и </head>

Локальные области

/local/include/seo/

• addAfterStartBody.php - после <body>
• addBeforeEndBody.php - до </body>
• addInHead.php - между <head> и </head>

Все включаемые области .../include/seo/ исключены из git'a, что дает возможность без головной боли заниматься проектом разработчикам.

Для проекта также реализован менеджер событий на js для сторонних скриптов, в котором лежат все взаимодествия с сайтом сторонних скриптов. По сути в менеджере событий лежат все цели, дополнительная логика, которая нужна на обработку событий.

Для событий E-commerce - сделан другой класс, который работает с rest, получая данные по заказу.

Реализовано решение по генерации фидов для каждого из сайтов по одному или двум шаблонам (google или yandex). В каждом из шаблонов генерации фида указывается шаблон пути, куда складывать выгрузку. Например, /upload/google_merchant#POSTFIX#.xml, где в #POSTFIX# - записывается SITE_ID.

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

Разработанный раздел нужен в основном для служебных целей. Возникла ситуация, когда на составных упаковках нужно выводить части, их материал и тип материала (либо цветом, либо текстом). Поскольку составных частей может быть несколько, то размер таблиц с данными по утилизации может быть объемным на упаковке. Поэтому разработана схема, когда на упаковку размещается ссылка на ее состав в виде QR-кода. Зайдя по ссылке - пользователь увидит ее состав. Это экономит место на упаковке, особенно для мелких упаковок с составными частями, где было бы проблематично все указывать.

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

То как это связано в админке приведено на изображении ниже. Данные помещены в инфоблоки и настроены на группы контент-менеджеров. Вбиты справочники материалов и типов материалов.

Раздел с документацией оказался полезным не только для этого проекта, но и для других проектов компании. Суть его проста - собрать и структурировать инструкции по использованию ресурсов компании.

В документацию вошли разделы

• Общее
  • Быстрый старт или с чего начать
  • О компании
  • Этапы работы с новинками
• Дизайнеру
  • Сжатие и подготовка
  • Визуалки и имиджиевые фотографии
  • Баннеры
  • Рассылки
• Маркетологу
  • Рассылки
  • Отправка рассылок
  • Счетчики
• Контентщику
  • Общее
  • Баннеры для главной
  • Баннеры для категорий
  • Товар на сайте
  • Что нужно для перевода сайта
  • Управление скидками и купонами
  • Переводы для админки
  • Настройка ленты вывода инстаграмма на сайте
  • Наполнение медиа-журнала
  • Наполнение B2B
• Менеджеру
  • Работа со сделками
  • Как привязывать контакты к компаниям
• Склад
  • Инструкция по сборке препака

Технически, для документации был выбран MkDocs. Разработана своя тема для документации, более сдержаные синие тона позволяют сконцентрировать внимание на самой инструкции. Используется docker-контейнер с mkdocs. Бекап документации настроен в git-репозиторий.

Для проекта разработан REST модуль, на основе штатного CRestProvider'а. Модуль умеет опрашивать другие модули на предмет объявленных действий, строить конечные точки входа, отдавать ответы, управлять правами доступа для групп.

Разработан интерфейс для модуля с использованием Vue и ElementUI. В интерфейсе отображены доступные методы для зарегистрированных CRestProvider'ов. У каждого метода может быть своя настройка прав доступа группы пользователей. После разработанного модуля, начался частичный рефакторинг всей темы, и переход на rest.

Когда проекту потребовалось деление на несколько сайтов, возникла идея поместить переключатель между сайтами. По началу переключатель был в виде выпадающего списка, там было всего 2 сайта - Русский и Английский. Но со временем список стал расти и я предложил идею - выносить переключение в модальное окно. Поскольку каждый сайт предполагает привязку к одной стране, то также возникла идея использовать карту мира, на которую переносить охваченные страны по сайтам.

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

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

На стороне бекенда разработан шаблон компонента bitrix:main.site.selector, в который выведен список сайтов, id компонента, и прокинут вызов карты с данными из списка сайтов на стороне фронта. 

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

Разработанное решение позволяет управлять генерацией карты сайта в формате .xml. Решение реализовано в виде модуля, такой формат позволяет использовать решение на других ресурсах. 

Особенности:

• Ручной/автоматический запуск генерации карты сайта
• Возможность использования нескольких вариантов карт для одного сайта
• Переключение протокола http/https
• Задать путь расположение файла с картой от домена сайта
• Управление статическими разделами на сайте
• Управление используемыми инфоблоками ресурса (будут выводиться только те, в которых выбран текущий сайт)
• Управление исключениями (на основе robots.txt можно сделать исключения для разделов или единичных путей)

Принцип работы

В основе генерации лежат внесенные пользователем данные по статическим и динамическим данным. Под статикой подразумеваются обычные разделы сделанные через статические файлы (index.php + .section.php), под динамикой - правила для инфоблоков. Исключения можно завать через файл robots.txt (каждое правило можно как выбрать, так и исключить), сам файл берется из корня сайта.

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

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

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