Drupal 8 Commerce. Проблемы с метатегами.

Аватар пользователя VasyOK VasyOK 19 ноября в 12:02

Приветствую специалистов по Drupal 8 Commerce!

Допустим есть товар заголовок Тапки производитель (термин) Armani.
Вопрос: как для товара по умолчанию задать метатег title "Тапки Armani купить в Киеве" ?

Для товара банально нет нужных токенов:

0 Thanks

Лучший ответ

Аватар пользователя VasyOK VasyOK 19 ноября в 21:19

На скрине admin/config/search/metatag/add

Да, действительно создал метатег по умолчанию, сохранил его, а потом при редактировании появилось то, что нужно. Спасибо!

Так все таки: нужно ли использовать ноды в качестве страниц товаров в D8? В 7-ке нужно было.

Комментарии

Аватар пользователя VasyOK VasyOK 19 ноября в 16:03

Или поступать как и в 7-ке: создавать ноду, к ноде приатачивать товар и к товару уже вариацию?

Аватар пользователя adano adano 19 ноября в 16:09

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

Аватар пользователя VasyOK VasyOK 19 ноября в 19:54

Т.е. через ноду - подход правильный?
Я пару сайтов на 7ке делал, на 8ке еще нет.

Аватар пользователя bumble bumble 19 ноября в 20:22

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

Аватар пользователя VasyOK VasyOK 19 ноября в 20:34

Что-то совсем непонятно.
Конфиг чего создавать? И где?
admin/commerce/config
?
Там есть тип товара и тип вариации товара. Между собой соеденены.

Аватар пользователя bumble bumble 19 ноября в 20:38
1

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

Аватар пользователя VasyOK VasyOK 19 ноября в 21:19

На скрине admin/config/search/metatag/add

Да, действительно создал метатег по умолчанию, сохранил его, а потом при редактировании появилось то, что нужно. Спасибо!

Так все таки: нужно ли использовать ноды в качестве страниц товаров в D8? В 7-ке нужно было.

Аватар пользователя Andruxa Andruxa 20 ноября в 4:56
1

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

Аватар пользователя bumble bumble 20 ноября в 5:21

Хм, точно не могу сказать, почему так. Но, могу допустить что из архитектурных соображений.

Всегда удобнее держать под контролем то что должно тобой контролироваться. Да и каплиться на другой компонент (ноду), который изначально не товар - явно костыльно.

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

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

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

Аватар пользователя Andruxa Andruxa 20 ноября в 5:23

Ну, проект всегда следует строить с прицелом на дальнейшее масштабирование.

Аватар пользователя bumble bumble 20 ноября в 5:27

Каталог -> Интернет магаз - это не масштабирование, это смена вектора и формата. С тем же успехом можно было бы "масштабировать" мотоцикл в автожир, к примеру. Если уж планируется расширение до полноценной торговой площадки - фц-нал магазина должен быть сразу заложен.

Аватар пользователя Andruxa Andruxa 20 ноября в 7:30
1

Каталог - это базовый функционал интернет-магазина. Разумеется, если речь не идет об LP с 2-3 товарами.
Как правило, необходимость добавления магазина возникает в b2b: сделали сайт-каталог продукции, спустя время, если сайтом занимались, приходит понимание, что можно увеличить его отдачу, добавив функционал формирования и оформления заказа.
В первую очередь, это касается дилерских продаж: вывели номенклатуру списком, фильтры-автокомплиты, и сиди себе набивай заказ.
Просто в случае с нодами, добавление магазина будет на порядок проще/дешевле. И так же на порядок будет выше вероятность, что это закажут делать.

Аватар пользователя bumble bumble 20 ноября в 12:21

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

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

Было круто иметь ввиду такую "перспективу" и возможность на ней сэкономить (кстати, а пригождалось ли в реальности, или было просто приятнее держать такую фичу в уме?), но теперь ее нет. Ничего не поделать.

Аватар пользователя Andruxa Andruxa 20 ноября в 13:18

завязывание на другие компоненты является unix-way, а не плохой практикой, а тут колхозят explorer.exe

Аватар пользователя bumble bumble 20 ноября в 13:33

Не самая подходящая аналогия, мягко говоря. Если я правильно понял и это про то что "программа должна делать только одну вещь, но правильно". Никто ведь не использует ноды в качестве сущности для ползователя, или для термина таксономии, а ведь можно было бы, если постараться. Так почему столько отрицания при выделении товара в свою стезю?

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

Аватар пользователя Andruxa Andruxa 20 ноября в 13:37

Нода - единица контента, и для дисплея продукта она подходит полностью, что в общем-то и подтверждается практикой commerce 1.
Сам физический продукт - да, имеет мало общего с контентом, и его перенос в отдельную сущность полностью оправдан. Но создание на ровном месте еще одной сущности, дублирующей функционал контента - ничем не обоснован.

Аватар пользователя bumble bumble 20 ноября в 14:18

Вполне обоснован. Функционал не дублируется, он просто схож в некоторых аспектах (в том что может являться "страницей", если исходить из примера).

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

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

Все это заведомо приводит к созданию "хрупкой" системы, и кроме прочего, привязываясь к другому компоненту, мы получаем ряд неудобств. А зачем? Ради экономии кода?

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

Развиваем мысль дальше. Представляем что в структуре материалов (нод) происходят какие-то серьезные изменения. Меняется апи, или структура в бд, к примеру. Что теперь? Бежать клепать патчики? Тратить еще кучу времени на анализ, тестинг, внедрение и обновление? А как с теми кто уже привязал свой кастом под эту реализацию? А сколько еще таких изменений будет в будущем? Зачем заведомо рисковать всей системой?

Более того - зачем тормозить развитие системы нод, создавая ее разработчикам такой груз ответственности, привязывая такой серьезный компонент как коммерц к их детищу и всем кто его использует?

Какая реальная необходимость всем этим рисковать для разработчиков? Ради того чтоб кто-то мог греть себя мыслью что ему не понадобится мигрировать теги лишний раз?

Аватар пользователя Andruxa Andruxa 20 ноября в 14:25
bumble wrote:

Все это заведомо приводит к созданию "хрупкой" системы, и кроме прочего, привязываясь к другому компоненту, мы получаем ряд неудобств. А зачем? Ради экономии кода?

Да-да, у меня тут как раз убунта из тысячи пакетов собрана. Такая, зараза, хрупкая.

Аватар пользователя bumble bumble 20 ноября в 14:36

Нет даже аналогии, не то что корреляции. И прямо противоречит нити суждений.

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

Аватар пользователя gun_dose gun_dose 20 ноября в 6:46

Ноды пусть и рудимент, но всё завязано на них. Например, вешаешь на товар комментарии, а они не показываются анониму, т.к. количество комментариев считается запросом, завязанным на ноды. Или контекстный фильтр вьюс: ID термина таксономии (загрузить ID со страницы материала) - аналогичной штуки для продуктов нет. И ещё пару таких приколов было. Очень отстойно, что разработчики коммерса, делая отдельную сущность, ничего этого не учли.

Аватар пользователя bumble bumble 20 ноября в 6:50

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

Аватар пользователя gun_dose gun_dose 20 ноября в 9:09

То есть если вьюс не умеет грузить термин со страницы товара, то ты предлагаешь, чтобы с нод тоже нельзя было?😆

Аватар пользователя bumble bumble 20 ноября в 11:40

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

Аватар пользователя marassa marassa 20 ноября в 13:07

А можно полюбопытствовать (хоть и оффтопик) - почему для товаров в коммерсе решили использовать кастомные сущности? Что именно не получилось реализовать на нодах? Сам не сталкивался, чисто для самообразования из праздного любопытства интересуюсь.

Аватар пользователя bumble bumble 20 ноября в 13:10
1

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

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

Зачем использовать для товаров что-то, что товаром изначально не являлось?

Аватар пользователя VasyOK VasyOK 20 ноября в 13:14

Я как делал сайты на Уберкарте и чучуть на Комерце именно потому что с товарами (пусть даже они по определению Адано "витрина") можно делать то же что и с нодами.

Аватар пользователя marassa marassa 20 ноября в 13:29

я не знаю истинных причин

Ну истинных причин никто не знает кроме разработчиков, но при плотной работе с модулем причины тех или иных проектных решений часто становятся очевидными.
У меня например достаточно сложный набор сущностей с обилием ER полей и т.п., практически ни в одной вообще не используется поле Body, в одной из сущностей даже не используется Title (хотя оно необходимо и его приходится генерить). Я всё это легко реализовал на бандлах/типах материалов, и за три года ни разу не пожалел об этом. Где надо - отбираю легко нужную мне сущность по бандлу, где не надо (а это как ни странно часто) - легко могу вывести в одной вьюхе материалы разных типов (а вот юзеров туда же - не могу, и это парит). Если бы всё было сделано на разных кастомных сущностях, то реальные проблемы от этого я предвижу сразу, а реальных преимуществ что-то не вижу.
Ну и кроме того, gun_dose совершенно прав, что многие модули Друпала (включая ядерный Views) заточены на ноды, и не всё работает с кастомными сущностями. Тут вопрос даже не в том, правильно это или нет, а в том, что это объективная реальность.

в проектировании не очень приветствуются практики многоцелевых сущностей

Можно ли вот этот тезис поподробнее раскрыть? Есть путь создания кастомных сущностей, есть путь создания бандлов/типов материалов на нодах. Какие именно сущности реального мира следует, а какие не следует делать на нодах, и почему?

Аватар пользователя bumble bumble 20 ноября в 14:24

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

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

Не правильно сравнивать создание конкретного проекта на Друпал и создание системы на Друпал (с помощью которой уже другие, потом, будут реализовывать конкретные проекты). В одном случае вы покрываете необходимый фц-нал с помощью имеющихся средств, в другом - реализуете средства для создания фц-нала.