11 июля 2016 в 19:57
Доброго времени.
Есть магазин drupal commerce: каталог-термины таксономии, facet api.
На странице термина-категории каталога, есть небольшое описание категории-поле обычное description термина.
Сейчас требуется сделать мультисайтинг, при этом товары на поддоменах должны быть одни и те же (отличаться будет цена), а вот страницы, описание терминов и все остальное - другое.
Посоветуйте какую схему мультисайтинга выбрать лучше в моем случае?
Вообще изначально хотел сделать обычным способом с общими таблицами, но мне из таблицы node, нужны только ноды типа display-product , а все остальные страницы - свои, это возможно обойти?
Если смотреть в сторону модуля domain access, то здесь запнулся на разном описании у терминов, т.к. не удобно будет создавать отдельные термины каталога..
Прошу помочь советом.
Комментарии
Делал подобное.
Кстати, мультсайтинг пока не запущен, но тут больше организационные вопросы.
По общим таблицам - был опыт разделения данных с помощью префиксов таблиц, не рекомендую: очень сложно поддерживать целостность данных, особенно когда добавляются новые поля/таблицы в базе.
Второй существенный недостаток - глобальный администратор сайта не видит картины в целом: на каждом домене будут свои значения из своих таблиц.
По разделению терминов таксономии - есть модули Domain Access Entity, это общий случай, подходящий для всех сущностей.
Для таксономии - есть отдельно Domain Taxonomy, удобен тем, что дочерние термины могут наследовать настройки доступа подоменно от родителей.
Сделано так: корневые термины - названия сайтов, у них настроен доступ к их доменам, а их дочерние термины - это фактически разделы каталога, они наследуют от родителей их настройки доступа.
Правда, пришлось выпилить корневые термины из меню и хлебных крошек.
В конце концов, реализовали разные цены у товаров для разных доменов с помощью Field collection:
Первое поле в коллекции - реализовано модулем Domain reference из песочницы, в нём хранится id домена, остальные поля - типа commerce price: list_price (та цена, которая зачеркнута), sell_price - по которой хотелось бы продать товар, min_price - цена, которой ограничивается результирующая цена, которая рассчитывается с учетом пользовательской скидки.
Т.е. для каждого домена - свой набор list- sell- и min price.
Таким же образом решен вопрос с описаниями товаров подоменно: коллекция из двух полей, одно из них - Id домена, второе - само описание.
При этом у Field collection есть неприятный баг при работе с vbo - т.е. просто отметить во вьюсе товары чекбоксами и массово назначить им цены/описания подоменно - не получится, в базе образуется куча мусора, который придётся чистить руками. Надо фиксить.
Также, пришлось написать свои Feeds importers, которые грузят из файла значения цен/описаний и пишут их в field collection item, в зависимости от того, на каком домене происходит импорт.
Ну, и синхронизация цен-остатков сделана по похожему принципу.
Далее, поскольку у вас фильтрация фасетами - видимо, используется search_api.
Наверняка, либо реализованы, либо скоро захочется реализовать фильтрацию и сортировку товаров по цене.
Следовательно - в индексе должны лежать значения цен так же подоменно.
Тут могу порекомендовать Search API Grouping - он может не только группировать документы индекса, но и денормализировать их по значению какого-либо поля сущности, надо - по id домена.
Значения Domain access - это не поле, а свойство сущности, поэтому его надо будет продублировать в отдельное числовое поле, скрыть его от шаловливых рук админа, и поддерживать в нём актуальные значения в зависимости от настроек доменного доступа.
И при индексации выдавать в индекс значения цен, актуальных для домена, который индексируется.
Так же, наверняка потребуются следующие модули:
Domain RobotsTxt
Domain Redirect
Domain Path
Domain Site Verification
Domain Views
Domains Metatag
ну и ещё пяток-другой, в зависимости от задач.
Это так, очень коротко.
@Andruxa неплохой мануал получился, с комментария. Спасибо!
Если есть желание - можете оформить в виде отдельного поста - повесим его на главную.
Спасибо за обзор.
Цены буду рассчитывать исходя из наценки для конкретного домена рулесами. Здесь, я думаю, проблем не возникнет.
«Сделано так: корневые термины - названия сайтов, у них настроен доступ к их доменам, а их дочерние термины - это фактически разделы каталога, они наследуют от родителей их настройки доступа.
Правда, пришлось выпилить корневые термины из меню и хлебных крошек.»
Это просто прямо ужас какой-то, например, если у меня 100 разделов каталога на 1 поддомен, а поддоменов 50... таксономия загнется...
Да и модуль Domain Taxonomy позволяет управлять доступом в целом к термину, отсюда и решение с корневыми терминами. Да и товары, тогда необходимо отностить сразу к 50 поддоменам-терминам?
Пока вижу одно боле-менее подходящее, но тоже жутко не удобное решение - это вообще отказаться от описания термина и использовать для этих целей блоки, вот только их тоже немереное количество понадобится...
А не проще сделать все сайты на отдельных базах и организовать экспорт нужных данных из "базового" во все остальные?
Наример этим:
https://www.drupal.org/project/migrate
https://www.drupal.org/project/migrate_d2d
Можно сделать рассчет цен прямо при миграции(экспорте-импорте).
В данном конкретной случае, думаю, не проще, тем более не вижу смысла плодить базы, если требуется всего-то только менять цены, которые "на лету" и так можно сменить. Да ресурсы на те же базы? Администрировать все сайты? Или писать экспорт изменений во все остальные базы при добавлении продукта? Это решение напомнить CTR-C CTR-V
Можно в одной базе с разными префиксами, тогда чать таблиц можно объединить, например пользователей и таблицы commerce.
Это настраивается 1 раз (migrate)
Еще вариант, использовать немного не по назначению функциональность мультиязычности.
Т.е. 1 "язык" - 1 домен со своим вариантом контента
Видимо вы немного не поняли суть.
Я не против завести 50 баз, но для хранения в них уникальных настроек для каждого сайта, таких как, например, описание, метатеги, кеши, т.е что разное. Но я не вижу смысла выносить, например товары и их дисплеи в каждую из баз, если, по сути, они одни и те же, а вот ноды другого типа - разные...
Это решение было продиктовано тем, что на разных доменах - разные структуры-иерархии разделов каталога, и сами разделы разные. Т.е. - у каждого домена - своё дерево.
таксономия загнется при большой вложенности терминов, при вызове taxonomy_get_tree() - оно и понятно, почему.
Но сайт спроектирован так, что стандартные средства таксономии практически не используются, не загибается.
Да, именно так.
Мы практически не пользуемся формами редактирования контента.
Как правило, для этого используется импорт-экспорт xls, это удобнее любой админки любой cms.
Иногда, что-нибудь быстро подправить - VBO.
Все я правильно понял-)
Не хочу принимать участие в сотворении монстра..
Мое дело - предложить, Ваше право - отказаться-)
@Orion76 об этом и не просят, за совет спасибо.
@Andruxa
«Это решение было продиктовано тем, что на разных доменах - разные структуры-иерархии разделов каталога, и сами разделы разные»
У меня все одинаковое, товаров всего 1000, без атрибутов, просто не хочется громоздить всего, ведь проблема, на первый взгляд, довольно простая...
На первый взгляд - простая. Аппетит приходит во время еды, я вам клянусь.
Опыт показал, что через полгода эти несколько одинаковых сайтов расползаются в несколько отдалённо похожих друг на друга сайта, и уже контент одного не лезет в другой.
Плюс администрирование заказов.
Нет, вот это точно не проще монстра, как минимум - по количеству головной боли.