13 января 2019 в 18:38
Здравствуйте. Есть прайс-лист одним файлом CSV на 40 категорий, 10 000 товаров и 300 характеристик на все товары, которые хранятся в этом прайс листе. В категориях при этом из этих 300 используются одновременно штук по 20.
Хотелось бы тупой способ, это когда один продукт, в котором все эти 300 полей характеристик и добавлены, чтобы не думать особо и импортировать весь прайс лист сразу через feeds. Естественно при добавлении уже сотни полей в продукт простой хостинг уже загибаться начинает. В feeds также при добавлении сотого соответствия, он думает по 10 сек. А еще и фильтры нужны Search Api+Facets. Добавил тестово 500 товаров со 100 полями. В принципе сам сайт работает нормально, но в админке уже одновременно 50 товаров не удалить, перегруз.
Никогда не пробовал сайты на VPS, но потянет ли VPS, или не стоить и пробовать?
Лучше тогда наделать 40 типов товара и к каждому уже добавить нужные поля по 20-30 штук ?
Opencart не предлагайте только, я там когда сайт делал хотел застрелиться, когда увидел методы загрузки картинок и списки в админке, да и многие другие очевидно нужные вещи, которых нет. А на нормальную платформу денег пока не дают.
Комментарии
А что есть нормальная платформа? Битрикс?
Я не знаю какая нормальная платформа, особо не изучал, просто думаю, что по сравнению с Opencart какая нибудь платформа за 30-40 тыщ наверно должна быть лучше. Не помню названий, но ползал по демо админкам и там было получше, для людей.
Скоро появится модуль для решения этой задачи))
Поясни) Ты пишешь?
Да, пишу. И как раз в ближайшие 1-2 недели планирую опубликовать. Если в двух словах, то вместо большого множества полей можно будет использовать одно поле. Да, это волшебство!)))
Ждём поста на друпал.ру)
Не самое лучшее решение, особенно для хранения данных.
И какие же минусы у этого решения? Особенно, учитывая то, что вы не в курсе технических деталей реализации))
Интересно. Не забудь анонс сделать, нужная вещь
Что, где, когда? А у меня только месяц, потом наверно пристрелят, если сайт не сделаю. Скорее всего буду медленно, но верно добавлять 40 типов товаров со своими полями.
Можно начинать стреляться прямо сейчас.
Месяц - это нереальный срок.
Не надо 40 типов товаров, справятся https://www.drupal.org/project/facets
Так facets я написал что и буду использовать. Только для фасетов то у меня 300 общих полей, вот вопрос то в том, как эти поля добавить, этого я не понимаю. Либо 300 полей в один товар, либо индивидуальные поля для каждой категории. А 300 полей в один товар не получается, всё дохнет. А поля нужны чтобы фильтрация была. Без фильтрации то вообще проблем нет.
За месяц думаю успею. Я уже импорт настроил, создал одну категорию с 6 подкатегориями и загрузил 1300 товаров через feeds. Пока всё отлично.
> А 300 полей в один товар не получается, всё дохнет.
Каковы параметры хостинга и выделенные Вам ресурсы?
А какие типы полей ? Таксономия, текст ? Для фасетов сразу лучше на таксономии делать поля. Проблема с разными вариантами можно решить например создав не очередной тип товара, а поле (таксономия или выпадающий список) тип товара, которому привязать зависимость полей через модуль Conditional Fields. То есть, при выборе поля тип товара появляется один набор полей, при выборе другого - другой. Как вариант.
Во-первых, с чего вы взяли, что таксономия лучше? Представляете, сколько будет терминов?
Во-вторых, Conditional Fields не решит проблему никоим образом, а только сделает страницу редактирования совершенно неюзабельной, он же грузит на страницу всё, а потом через js скрывает лишнее.
Тут основная проблема в самих полях и их количестве. Я видел магазины, где есть поля вроде "мощность двигателя", "мощность насоса", "мощность нагревателя", и это ещё можно как-то стерпеть, но когда начинаются всякие метизы - типа гайки, болты и прочее, то там могут быть поля типа a, b, c, d, d1, d2, d3, D, D1, D2 и т.д. И на данный момент у этой задачи нет совершенно никакого вменяемого решения. Под вменяемым я понимаю не только работоспособное, но ещё и с адекватным UX, чтобы контентщику не нужно было ломать голову над структурой и заполнять 100500 форм.
Таксономия лучше для фасетов тем, что их потом можно будет использовать для SEO. Facet Api + Facet API Pretty Paths +Metatag Taxonomy Facets = полно отличных посадочных страниц. С простыми полями так не сделаешь. А то потом когда после разработки доходит до SEO, оказывается что кроме страниц товара и продвигать то нечего, после различных решений разработчика.
Я предложил один из вариантов. Друпал вообще громадная машина, которая даже в обычной commerce guys сборке задыхается и грузит простой хостинг по страшному. Тут не идеален ни мой вариант, ни с кучей вариаций товаров. Будем подождать Ваш модуль
+1 за решение.
Я использую по возможности в приоритете словарную таксономию для характеристики опций товаров, и не разочарован.
Господа, мне в детстве турник на голову упал, а недавно я в столб пешком врезался, в телефон смотрел, можно поподробнее. Терминами - это значит что например есть характеристика "цвет". Это поле я делаю ссылкой на словарь таксономии, и при импорте через feeds в эти поля будут создаваться термины "серый", "белый", "голубоватый", по ним и фильтрация потом будет, так? Скажется на скорости сайта?
Хостинг скорее всего какой нибудь VPS за 1000 руб в месяц наверно будет.
И про "Conditional Fields". Не работал с этим модулем. Я так понял он подгружать будет поля в зависимости от выбранного типа продукта. Вручную понятно, всё сработает. А feeds сможет импортировать корректно в такой тип продукта товары?
Еще забыл сказать что у меня 10 троек в аттестате, приходится вот теперь сайты делать, а мог бы быть каким нибудь учителем в школе или математиком-теоретиком.
В общем, по 40 товарам с индивидуальными полями у меня всё работает отлично. Производитель и категория у меня ссылками на термины, остальные характеристики просто полями. Фильтры фасетами работают, товары автоматом грузятся, ничего не тормозит пока вообще и в этом я уверен что оно будет работать. Единственный минус, нужно типов 40 товаров.
А вот все поля если делать терминами, я не пойму, что это даст и как. Т.е. будет один словарь "характеристики". В товар я буду добавлять например поле "цвет", тип: "ссылка на термин таксономии", в качестве словаря выбираю "характеристики". Соответственно feeds загрузит в это поле все имеющиеся цвета, они попадут в словарь "характеристики". Создам второе поле - "тип управления", тип: "ссылка на термин таксономии", в качестве словаря опять выбираю "характеристики". Опять туда feeds напихает новые термины. Получится у меня словарь "характеристики", состоящий из несколько тысяч терминов без группировки, все значения подряд. Не пойму, что это даст. Опять же нужно 40 типов товара делать. Или я неправильно вообще понимаю.
Не нужно все термины характеристик делать в одном словаре. Создаете словарь Цвет - туда цвета добавляете, словарь Производитель - производителей и.т.д. Их будет много конечно, но это даст в будущем возможность эффективно продвигать сайт. Так, представим что нужно будет продвинуть запрос в будущем например: Наименование группы товаров+производитель+цвет, а у вас ввиду того, что категоризация сделана обычными текстовыми полями а не терминами, не будет такой страницы, со своими уникальными метаданными и ЧПУ. Commerce по умолчанию для категоризации использует термины таксономии, даже цвета, и это может и не так удобно, но правильнее с точки зрения потенциала сайта в будущем.
Выборку "бренд + категория" можно сделать вьюсом. И эти два поля действительно принято делать таксономией. Но делать термины "Оперативная память 2ГБ" или "ширина 18мм" - это глупость. Даже с точки зрения СЕО-продвижения в этом нет никакого смысла, потому что люди ищут "Телефоны самсунг", а не "Телефоны самсунг с оперативной памятью 6ГБ, амолед-экраном, NFC-модулем, несъёмной батареей и российской сертификацией". Плюс можно сделать словарь "Тэги" и делать через него посадочные страницы типа "Унитазы по скидке" или "Пылесосы с аквафильтром".
Прошу ещё раз заметить: у автора около 300 характеристик - это по вашему способу будет 300 словарей. И 10000 товаров по 20 характеристик в каждом - это тысячи (или десятки тысяч) терминов. Такой сайт гарантированно ляжет после первой загрузки контента.
Согласен, абсолютно все характеристики делать словарями нет смысла
"Естественно при добавлении уже сотни полей в продукт простой хостинг уже загибаться начинает."
Как только поступит заказ на загнуть хостинг обращусь к вам.
все намного проще
нужен всего один словарь таксономии
но с несколькими уровнями.
Уровень 1 - Наименование параметра
Уровень 2 - Значение параметра
Ну да, когда я начал массовые операции производить с товарами на пробном сайте, удалять, добавлять по 50 штук, у меня все загнулось, наложилось какое то ограничение, потом я и одного товара удалить не мог, ошибка на сайте.
А как feeds в многоуровневый словарь будет значения писать?
Оставлю наверно как есть, бренд и раздел терминами, остальное - полями.
Понял, сначала двухуровневый словарь сделать и забить все характеристики и значения, тогда feeds новые не будет добавлять. Но это еще плюс работа, и если появится новое значение характеристики, оно попадет на первый уровень.
В серверах и остальном мало понимаю, но если я начну парсить сразу весь прайс лист на 10000 товаров, это вообще реально? Или хостинг такого не пропустит. У меня просто 502 ошибка, если больше 1000 товаров за раз.
Что то не пойму никак. Вот сделал я типы товаров 10 штук, сделал 10 search index, 10 групп фасетов, сделал 10 views, загрузил все товары, все работает быстро. Категория у товаров таксономией сделана. И вот теперь я не врублюсь, как мне сделать то вывод этих товаров с фасетами по клику на термин словаря "категории". То как обычно я выводил content type в drupal 7 по типу контекстного фильтра has taxonomy term id в данной связке то не работает.
Индекса хватило и одного, тогда был бы олин вьюс и один набор фасетов. Чтобы фильтровать по таксономии, нужно добавить в индекс соответствующее поле и контекстный фильтр добавлять по этому полю. В семёрке с Search API это делается аналогично.
Да я сначала один индекс сделал, потом запутался в этих сотнях полей, решил разделить, мне так спокойнее. Поле категории товара, которое у меня сделано терминами, в индекс добавлено. Вот например есть у меня тип товара "вытяжки". Для него сделан search index, views и facets. В этих вытяжках товары еще делятся на 6 подкатегорий (настенные, встраиваемые и т.д., прописаны терминами теми же). Фасетами у меня сделаны эти подкатегории, проблем тут нет, выбирать можно. Но хотелось бы терминами, чтобы по терминам тыкать и попадать на эти подкатегории, чтобы заголовок этих подкатегорий был нормальный, breadcrumbs и меню легче делать. Так вот если я в этом views добавляю контекстный фильтр по этому термину категорий (Товар datasource: Категория вытяжек » Термин таксономии » Название), то пусто на страницах термина, одни пустые фасеты. Контекстные фильтры мне туго даются, никак не пойму. Раньше просто выучил фразу "содержимое has taxonomy term id -- provide default value -- taxonomy term id from url". Говорила мне мама - учись на плотника, пригодится.
Так, я понял. У меня в search index отправлено название термина, а нужно было ID. Всё заработало.
А не получается все поля в один индекс, по крайней мере на openserver. Какие то ошибки с базой вылазят.
Drupal\search_api\SearchApiException: SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs: ALTER TABLE {search_api_db_kholodilniki_vstraivaemye} ADD `field_aerator_1` VARCHAR(255) DEFAULT NULL COMMENT 'The field\'s value for this item'; Array ( ) in Drupal\search_api_db\Plugin\search_api\backend\Database->fieldsUpdated() (line 1081 of C:\OSPanel\domains\sfkkk.ru\web\modules\contrib\search_api\modules\search_api_db\src\Plugin\search_api\backend\Database.php).
Потом еще что то про макс. 64 ключа SQLSTATE[42000]: Syntax error or access violation: 1069 Too many keys specified; max 64 keys allowed:
Это случается, когда в индексе меняют тип полей и поле, в котором уже проиндексированы длинные значения, содержит значение, которое не вписывается в новый тип. В таких случаях можно удалить поле и создать заново.
А вот 64 ключа - то хз. Наверное слишком много фильтров.
Еще вопросик. Например нужно через feeds загрузить категорию товаров "вытяжки". А в самом прайс листе категорий много, а нужны только вытяжки. Галка "автоматически создавать термины" отключена. Соответственно feeds может загрузить только в категорию "вытяжки". Но он я так понял всё равно грузит все 10000 товаров, а потом выдает ошибки, что нет такого термина, и это происходит очень долго. Нельзя ли что нибудь сделать, чтобы если например категория из прайс листа не существует в словаре таксономии, то feeds быстренько пропускал такие товары. Пока только в ручную делю csv по нужным разделам.
За незнанием php придумал туповатый способ. Используя feeds tamper добавил "Find and replace text" и заменил все ненужные категории в прайс листе на пусто (ничего не вводил на что заменять). А в конце добавил этим же тампером "Make this field required. If it is empty, the item will not be processed."