nogocuHoBuk

А встроенный функционал не подходит? Итог на сайте будет таким: Поклацать "переключатель" можете тут: https://shop.webdd.in.ua/ipod-classic.html

Глянул на сайт донор ещё раз. Там 100 позиций товаров. В 80 примерно не более 20-30 "перелинковок) и только в нитках их около 600.... Так что фраза про имеет право на жизнь... Но, опять же, нужно чтобы ТС хоть ЧТО_ТО написал в теме. А то гадаем на кофейной гуще

Не понимаю откуда она может взяться при юзании собственной функции с двумя джоинами на получение цвета и линка для перелинковки в карточке. Тем более если таблицу "связей" индекснуть корректно. Тут же не нужно для каждого продукта getProduct() дёргать. Это ж всего 600 строк из индексной страницы с 2мя джоинами по индексным полям. Ну тут то без вопросов. Опять же, для ускорения желательно хранить кастомное поле в самой oc_product чтобы дёргать вместе с product_id. Можно даже что-то из имеющегося неиспользуемого jan, isbn, mnp etc... Тем более на примере числовой формат от 0 до 9999 с ведущим нулём. Во всяком случае поверхностно сложностей не вижу.

Зато нагрузка, в принципе, околонулевая, если учесть что сами связки хранятся непосредственно в таблице товаров (образно можно реализовать подобием product_image, т.е. 2 столбца. main_product_id и dop_product_id) Ну а на фронте тянуть "дай main где dop это я, и если пусто, то дай всех dop'ов, где я main) И, опять же, всё зависит от текущей реализации. Если магазин уже существует и в него уже добавлены для каждого цвета своя карточка - то решение вообще лучшее.

Выбор решения будет зависеть от многих факторов. Для примера Есть товар - нитки. 600 цветов. Как Вы ведете учет складов? На складе ж это не одна номенклатура, а 600, верно? т.е. красных - 100, зеленых - 120, синих - 200 etc... При реализации через опции нужно будет переделывать логику синхронизации со складом, так как теперь количество товара (в карточке) нужно учитывать как общее количество ВСЕХ доступных цветов, а в каждой опции конкретно проставлять количество каждого цвета. Если же у Вас учет каждого цвета в отдельной карточке - тут свой подход нужен. В Админке все останется без изменений (разве что добавить возможность "связать" карточки товара, а вот на фронте нужно будет выводить, например, по каноникалу. Очень мало вводных данных чтобы советовать что-то конкретное.

По ресурсозатратности и времени выполнения ж то же самое, вроде. Не? Да и для того, чтобы нужно запустить всё тот же цикл перебора полученных товаров. Тут же главное суть... не. Имеем сто товаров 99 порублю 1 за 100 рублей в вашем случае средняя цена (100+1)/2 примерно 50 руб в реальности (99+100)/100 примерно 2 руб

Нужно править и контроллер и модель и шаблонизатор twig. В модели есть функция получения количества товаров в категории. Достаточно просто вызвать её в контроллере, передать данные в твиг и отобразить, а вот с мин, макс и средней ценой чуть "интереснее" Нужно создать функцию, которая будет возвращать эти значения. Т.е. обращаемся к БД, говорим - дай все товары, которые в нужной нам категории. Перебираем их циклом и используем поле price для сравнения. Перебором находим мин и макс, а среднее получаем методом сложения всех прайсов и делим на количество товаров. Но функция будет вешать Ваш сайт, особенно если в ней много товаров, потому результат выполнения нужно "кешировать", например писать в статичный файл в json, указывая в нём все 3 значения и "срок годности" . И при обращении к категории проверять файл на существование, а затем на срок годности. Если устарел или не существует - запускаем функцию вышеуказанную и снова пишем в файл. А если существует и дата в порядке - берем данные из json. По реализации - часа полтора-два (без стилизации вывода), т.е. получение, кеширование и передача данных шаблонизатору. При желании можно повесить рассчет и кеширование на крон, чтобы тех редких юзеров, на участь которых может выпасть "устаревание" - не напрягать, а рассчитывать всё в фоне и поддерживать кеш в актуальном состоянии. А при НАСТОЯЩЕМ желании сделать красиво, можно так же обновлять кеш из админки каждый раз, когда добавляется, удаляется или редактируется товар, в зависимости от категории, в которую он входит. Если это "сложно" или "дорого", то вариант предложенный @Tom выше - идеальное решение.

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

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

Я ж понятия не имею как Вы всё выводите и что обрабатываете. По кускам кода сложно "догадаться" Для начала верните как было у Вас в первом посте т.е. Только вместо $options = $this->model_catalog_product->getProductOptions($result['product_id']); будет $options = $this->model_catalog_product->MygetProductOptions($result['product_id']); Только эти правки увеличат скорость обработки (учитывая сколько у Вас групп опций и самих опций в каждом товаре), как минимум раз в 10.

точно тут смотрите?

СОздаете в меню 3 ссылки с параметром, например, type_catalog и 3-мя разными значениями M,W и С В хедере ловите $this->request->get('type_catalog') и пишете значение в сессию В каждом товаре добавляете либо аттрибут, либо кастомное свойство (зависит от реализации) и прописываете для всех товаров значения M,W или С Ну и при выборке товаров каталога применяете фильтр по этому свойству (можно написать свою функцию аналог getProducts) который будет отбирать только нужные товары. Зависит от Ваших навыков и опыта.

В catalog/model/catalog/product.php полностью копируете функцию getProductOptions() В скопированной функции переименовываете название на MygetProductOptions и после $product_id добавляете ещё один параметр - $option_id можно с дефолтным значением: Получится так: public function MygetProductOptions($product_id,$option_id = 11) { А в строке запроса, где $product_option_query = ... добавляете фильтр по опции, т.е. перед po.product_id ставите проверку Получится примерно так: было WHERE po.product_id стало: WHERE o.option_id = '" . (int)$option_id . "' AND po.product_id Итоговая функция: public function MygetProductOptions($product_id, $option_id = 11) { $product_option_data = array(); $product_option_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "product_option po LEFT JOIN `" . DB_PREFIX . "option` o ON (po.option_id = o.option_id) LEFT JOIN " . DB_PREFIX . "option_description od ON (o.option_id = od.option_id) WHERE o.option_id = '" . (int)$option_id . "' AND po.product_id = '" . (int)$product_id . "' AND od.language_id = '" . (int)$this->config->get('config_language_id') . "' ORDER BY o.sort_order"); foreach ($product_option_query->rows as $product_option) { $product_option_value_data = array(); $product_option_value_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "product_option_value pov LEFT JOIN " . DB_PREFIX . "option_value ov ON (pov.option_value_id = ov.option_value_id) LEFT JOIN " . DB_PREFIX . "option_value_description ovd ON (ov.option_value_id = ovd.option_value_id) WHERE pov.product_id = '" . (int)$product_id . "' AND pov.product_option_id = '" . (int)$product_option['product_option_id'] . "' AND ovd.language_id = '" . (int)$this->config->get('config_language_id') . "' ORDER BY ov.sort_order"); foreach ($product_option_value_query->rows as $product_option_value) { $product_option_value_data[] = array( 'product_option_value_id' => $product_option_value['product_option_value_id'], 'option_value_id' => $product_option_value['option_value_id'], 'name' => $product_option_value['name'], 'image' => $product_option_value['image'], 'quantity' => $product_option_value['quantity'], 'subtract' => $product_option_value['subtract'], 'price' => $product_option_value['price'], 'price_prefix' => $product_option_value['price_prefix'], 'weight' => $product_option_value['weight'], 'weight_prefix' => $product_option_value['weight_prefix'] ); } $product_option_data[] = array( 'product_option_id' => $product_option['product_option_id'], 'product_option_value' => $product_option_value_data, 'option_id' => $product_option['option_id'], 'name' => $product_option['name'], 'type' => $product_option['type'], 'value' => $product_option['value'], 'required' => $product_option['required'] ); } return $product_option_data; } Ну и теперь в контроллере вызывайте вместо $options = $this->model_catalog_product->getProductOptions($result['product_id']); нужно заменить на $options = $this->model_catalog_product->MygetProductOptions($result['product_id']); А если нужно сменить в запросе группу, то так: $options = $this->model_catalog_product->MygetProductOptions($result['product_id'],12); Т.е. запрос будет по группе 12

Общее количество в категории не играет роли. Запрос ограничен количеством на странице. А если уменьшить количество товаров до 12, например? Просто 48 товаров, обход циклом. В цикле 5 групп опций, да по 6-20 опций. Делать "по аналогии" - равносильно прямому запросу. Это не ускорит выполнение. Нужно как-то оптимизировать сам запрос и написать свою функцию получения опций с фильтром (к примеру пропустить какие-то, ) типа: MygetProductOptions($result['product_id'],$filter); ну а в фильтре уже указывать группы опций, или прямо задать какие именно опции нужны.

Это Вы уже что-то совсем не то делаете. Сама getProductOptions всё это уже возвращает. А сколько у Вас товаров в этой категории. И в среднем сколько опций на товар?

Добрый. Что именно Вы сделали "один в один"? То, что процитировали? Отключили ошибки в админке? Это НИКАКИМ образом не влияет на заказы, их открытие, редактирование и прочее. Подобная опция отключает показ ошибок, если таковые имеются. Не более. Пишите в личку - попробуем разобраться с Вашей проблемой

Ваша текущая ошибка - "ВНИМАНИЕ: Ваш IP адрес 89.200.234.223 не имеет доступа к API! Ваш" и "Ваш API ключ недействителен" Вы точно проделали все операции из предыдущего решения? Админка - Система - Настройки (там выберите свой магазин) - Вкладка "Сервер". Ищите там "Показывать ошибки" и ставите "Нет". Опять же, названия пунктов смысловые, зависит от Вашего перевода. Но в конкретной ситуации отключение ошибки не исправит проблему с API . Просто теперь они будут выводиться красным вверху заказа.

Так и есть. Я "API" в тексте даже не заметил А полный текст ошибки "У Вас нет разрешения на доступ к API" Вот это может помочь:

Про готовый модуль не в курсе, но подобное реализовывал вот тут: https://iglaz.ua/apple-iphone-12-128gb-black-mgja3 Делалось и для цвета и для объема. В админке есть блок "связей" для указания дополнительных товаров-цветов. В карточке "главного" товара указывается его цвет А у "Дополнительных товаров" помимо цвета нужно выбрать "главный товар" (он же будет каноникалом для всех остальных цветов Модуль не делался, так как вывод зависит от шаблона. Потому в любом случае нужно "допиливать". Если заинтересует - пишите в ЛС.

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

Все подобные алерты в опенкарте показываются при ajax запросах при включенном показе ошибок. Т.е. Вы меняете статус заказа, происходит ajax запрос, и скрипт ждёт ответ в формате json, а получает html страницу на которой в самом верху какой-то warning или notice. Ну и при невозможности распарсить json скрипт выдает сообщение "SyntaxError: Unexpected ..." Отключите показ ошибок и, скорее всего, всё заработает.

Вы предлагаете "закостылить" проблему? В принципе можно, но... Ведь по факту товар был некорректно удален. Удалена запись из таблицы oc_product (это можно понять из запроса, так как выборка именно p.product_id) А остальные таблицы скорее всего не тронуты. И в запросе с *, который выше этих самых "product_id" будет как минимум 5. И именно по ним можно определить какой из товаров удален некорректно. Ну и зная product_id можно смело вызвать из /admin/model/catalog/product.php функцию deleteProduct($product_id) и избавиться от хвостов...

Кидайте доступы в личку. Я пока за ПК. Можете создать временные

нужно дебажить. Без вариантов. Кстати. А заскриньте oc_order_history для последних заказов (которые после "правок"

Ну в данный момент пока не ясно плохо ли это. У Вас, видимо, у статуса "Принят" order_status_id = 1, или нет? Только не меняйте order_status_id в БД В настройках системы смените статус закза по умолчанию на любой другой. Например на Оплачен или Отменен