a13x

Цена обновлена. 149$. Добавилось: Возможность удаления всех добавленных ранее товаров из YML файла 2 режима работы: "Импорт, обновление" или "Только обновление" https://yadi.sk/i/XhRLjRkYtBbapw https://yadi.sk/i/0E8LWqNlUawTfQ

1.4.2 - не надо, тех что есть вполне хватает для 99% файлов 1.4.4 - если кому то понадобится больший процент это легко поправить. 2.1 - обычно шаблон это поставщик, в метку записывается шаблон+артикул товара. Опять же в большинстве случаев того что есть за глаза.

1.3 на первом скрине активен 1-ый шаблон, они там пишутся в строку https://yadi.sk/i/pZ4N2koc2QxsCA 1.4 в основном всё написано в описании к модулю, но напишу: Режим работы: Импорт+Обновление, Только обновление Разделитель категорий: ";" "," "\n" Разделитель подкатегорий: "/" "|" Наценка: 0 .... 100% Отключить товары: Да\Нет Не импортировать без цены: Да\Нет

1.1 настройки по шаблону сохраняются в файле config.json, заново создавать ничего не надо, туда же записываются соответствия по столбикам, следовательно при загрузке обновленного прайса всё подтянется автоматом. 1.2 да, можно создать сколько угодно шаблонов со своими настройками. недавно установил на симплу, тоже переделанную, ничего, всё работает. "И подобных вопросов много..." - если подобных вопросов много пишите все, зачем 2-мя ограничиваться.

Что умеет: Создание шаблона для работы с товарами из эксель-файла. Отключение товаров (которые были добавлены через этот шаблон) и включение только тех что были найдены в процессе импорта/обновления Режим работы: импорт + обновление / только обновление Возможность задать соответствие колонок Предпросмотр, корректировка, сохранение соответствий для текущего шаблона Работа с файлами CSV, XLS, XLSX (PHPEXCEL для xls, BOX/SPOUT для XLSX т.к. в PHPEXCEL бывают утечки памяти из-за чего некоторые файлы прочитать невозможно) Переименование названия категори

{$product->category->path[0]->subcategory[0]->name} может так?

Жесть, что за чушь тут написана? Я рассказал в чём проблема, дал решение, мне ещё и написать код который это будет устранять? Мне это не надо, у меня всё отлично работает на моей сборке.

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

Почему для одного, для всех у которых есть эта категория. Т.е. Если меняем категорию с id = 400, то выбираем все товары где есть эта категория и все дочерние (500), удаляем привязки (400 и 500), добавляем нового родителя (т.к. мы перенесли 400 в например 200) для 400-ой категории и всех дочерних категорий (напр. 600 и 700). Хотя по видимому 400-ую даже удалять не надо, только его дочерних (500).

Если все дочерние в передлах родителя то не думаю что должны быть проблемы. Если же переносить за пределы родителя то надо уже более детально смотреть что и как.

Пример: Есть товар А с id = 10 который находится в категории M с id = 500. Категория М вложена в категорию L с id = 400, L в свою очередь вложена в K = 300. В таблице соответствия products_categories у нас 1 запись: 10, 500, 0. Соотв. при входе в категорию K в запрос идут все дочерние ID: (300,400,500). Чтобы этого избежать надо в таблице соответствия products_categories добавить ещё 2 записи: 10, 400, 0. 10, 300, 0. Тогда при заходе в категорию К достаточно будет проверять только по ID 300. Да, записей в таблице возрастёт, но лучше больше записей в таблице, чем запросы с кучей ID

Что значит нерациональность? Если у вас есть идея как исправить это - пишите, но боюсь что таковой нет. Я написал как это можно исправить, но врядли кто-то это будет делать, лучше вон перепишут симплу, только толку от этого как всегда ноль!

тут как вариант хранить в БД вложенность всех категорий для товара, а не так как сейчас, только для посл. категории.

нет, это не много, в моём случае у человека было 800 подкатегорий в одной. В вашем случае скорее всего очень дешевый хостинг ограничивает ресурсы. Перейдите на тариф повыше. Кол-во товаров не особо играет роли, по крайней мере не в таком кол-ве.

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