mpn2005
-
Публікації
3 222 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача mpn2005
-
Добрый день. Под данный шаблон есть готовая адаптация. Адаптацию оплачивать не требуется. По модулям надо смотреть. Обычно сложностей сильно не возникает, если модули с открытым кодом. -
Добрый день. Можно в phpMyAdmin запросом: UPDATE oc_product_option_value SET subtract = 0 oc_ - заменить на свой префикс.
-
Добрый день. Скиньте в личку доступ на фтп и в админку. Если сами не справитесь. И ссылку на образец товара.
-
Ссылка на модуль не поможет. А вот доступ на фтп и в админку - поможет. Модулей много всяких разных и под них надо просто добавить правки в модификатор. Учитывая множество всяких модулей и фильтров, все эти правки не включаются в релиз. Т.к. модификатор раздуется до приличных размеров и будет содержать много мёртвого кода.
-
Не всегда. Тут есть исключения. Добрый день. Если включен 301 редирект на родителя, то там будет родительское описание. Если редирект не включен и товары продвигаются отдельно, то там будет описание именно того товара, с которого пришли (В том числе и если включен режим полной замены ссылок).
-
Увеличьте php параметр max_input_vars Например до 50000. По умолчанию обычно 1000 - этого очень часто оказывается недостаточно. Таких тем на форуме достаточно. Вот одна из них.
-
Добрый день. Под данный шаблон есть готовая адаптация. Поэтому адаптацию оплачивать не требуется. Иногда надо по мелочи поправить, т.к. могли произойти изменения в шаблоне. Такие правки обычно делаем без дополнительных оплат.
-
С таким количеством SeoPro точно не должен влиять на производительность. Если при его включении начинает тормозить - где-то есть странная проблема.
-
При включении SeoPro начинает тормозить? Довольно странно. Пробовали вариант с кэшированием и без? Сколько товаров и сколько категорий в магазине?
-
Включите в настройках SeoPro. Тогда крошки будут формироваться по главной категории товара.
-
Добрый день. Не переживайте, никто про вас не забыл. Просто скопилась очередь по поддержке, надо и другим тоже уделить время.
-
Есть товары, для которых можно по цветам или моделям составить полноценное описание. Вот для таких товаров имеет смысл держать совсем отдельные карточки товара. Это как правило крупная бытовая техника. Т.к. с цветом может отличаться и модель в линейке. Вот для таких товаров это может быть актуальным.
-
Добрый день. Для ОС3 - это по сути совсем другой модуль. Т.к. там шаблонизатор twig. И, скорее всего, может понадобиться адаптация под тему. Вы используемый шаблон обновили с ОС2 на ОС3 или установили новый? Я пока приостановил продажи на данной площадке. Т.к. жду решения вопроса по организации выплат. Но пока админнистрация форума молчит уже почти три недели. И я не получил никакого ответа. Поэтому возобновление продаж может оказаться под вопросом. Если данный вопрос не решится, то есть вероятность, что сниму данный модуль с продажи и на остальных площадках.
-
Добрый день. Простите за столь поздний ответ. Это проблема модуля, который содержит файл "quantity_per_option_option_form.twig" Мой модуль не содержит такого файла.
-
Везде в коде вы пишите про поле SKU, а в сообщении об ошибке говорится про поле EAN. Проверяйте что и как написали.
-
Так неправильно. Все данные в массиве $order_info. Сделайте в контроллере print_r($order_info) И проверте, что возвращает модель.
-
Тут ошибка. Надо так: 'mpn' => $order_info['mpn'], Там же из $result только номер заказ берётся. По умолчанию там не все поля из заказа модель возвращает.
-
А зачем туда что-то вставлять? Симпла сама с этим справляется. Чтобы что-то туда вставить нужно чётко понимать, что у куда надо вставить. Выборка и вставка данных - это не одинаковые процессы.
-
Тут уже от задачи зависит. Добавит дополнительных запросов. Зато не будет приключений, если в заказе станет больше одного товара.
-
Да проще не придумать в контроллере сделать так: $order_mpn = ''; $order_products = $this->model_account_order->getOrderProduct($result['order_id']); foreach ($order_products as $order_product) { if (!empty($order_product['mpn'])) { $order_mpn = $order_product['mpn']; break; } }
-
Так с этого и надо было начинать. Тогда что-то вроде этого: $order_query = $this->db->query("SELECT o.*, p.mpn FROM `" . DB_PREFIX . "order` o LEFT JOIN `" . DB_PREFIX . "order_product` op ON (o.order_id = op.order_id) LEFT JOIN `" . DB_PREFIX . "product` p ON (op.product_id = p.product_id) WHERE o.order_id = '" . (int)$order_id . "' AND o.customer_id = '" . (int)$this->customer->getId() . "' AND o.order_status_id > '0'"); Но я бы так всёравно не делал, а делал по человечески. Т.к. это получается костыль.
-
Заказы - это заказы, а товары в заказе - это товары. В одном заказе может быть 10 товаров с разными полями. Это поле не логично прикреплять к заказу. Его надо прикреплять к товару. После строки: $order_info = $this->model_account_order->getOrder($result['order_id']); Получайте данные по товарам. Что-то вроде такого: $order_products = $this->model_account_order->getOrderProduct($result['order_id']); В модели у метода getOrderProduct надо будет добавить JOIN как писал выше. И в контроллере перебирайте и доставайте нужные поля. Только надо учитывать, что товара может уже и не быть. По хорошему нужные поля нужно тянуть в таблицу order_product. Вот это в цикле вообще лишнее.
-
Если это в списке заказов, то для каждого заказа делаем такой запрос.
-
Добрый день. Можно вот так: $order_product_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_product op LEFT JOIN " . DB_PREFIX . "product p ON (op.product_id = p.product_id) WHERE op.order_id = '" . (int)$order_id . "'");
