Prooksius

Можно и так, но там такой малюсенький файлик, я не думаю, что из-за этого будут тормоза.

Может быть в конфигах указаны разные БД в админке и на фронте? Или в тех же конфигах фронта и бэка указаны разные префиксы для БД. В итоге БД одна, а таблицы на фронте и в админке разные. Ну как вариант, чего бы проверить...

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

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

Всегда удручало в опенкарте, что нужно менять отображение плитки товара в куче мест, если нужно что-то поменять. Это и в модулях (например, на главной), и на на стр. категорий, и в поиске, и на производителях, и в товаре, в рекомендуемых, вообщем мест полно. И везде по идее обычно плитки одинаковые. Практически не встречал реализаций, чтобы они были разные в разных местах. В итоге сделал отдельный файл вывода самой плитки и подключаю его в шаблонах вывода категорий, поиска, модулях.... везде. В результате чтобы поменять внешний вид плитки, надо залезть в один файл. Подключаю просто: <?php foreach ($products as $product) { ?> <? include 'product_thumb.tpl'; ?> <?php } ?> ну и надо учесть путь, где файл лежит.

Тут так просто не подскажешь, потому что цена выводится в десятках разных мест. И все их надо учесть. Перечислять тут их все - ну просто нереально. Например, вот есть категория, нам нужен файл контроллера категории catalog/controller/product/category.php и в ней надо искать нечто подобное. $price = $this->currency->format($this->tax->calculate($result['price'], $result['tax_class_id'], $this->config->get('config_tax')), $this->session->data['currency']); Оборачивать это дело в условие (если ID товара == ### - то как-то иначе форматируем цену, а иначе - как было раньше) Можно для облегчения нужного форматирования залезть в system/library/cart/currency.php И добавить там новый метод, к примеру, format_plus, в котором сделать некое другое - нужное - форматирование. и тогда в контроллере получится как-то так: if ($result['product_id'] == ###) { $price = $this->currency->format($this->tax->calculate($result['price'], $result['tax_class_id'], $this->config->get('config_tax')), $this->session->data['currency']); } else { $price = $this->currency->format_plus($this->tax->calculate($result['price'], $result['tax_class_id'], $this->config->get('config_tax')), $this->session->data['currency']); } Но опять же, мест, где надо так сделать - уйма. И к тому же это - изменение кода, а при установке каких-то модулей, если они модифицируют файлы - могут быть проблемы с совместимостью, потому что код вы уже изменили, а модификаторы ожидают, что этот код сохранится прежним.

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

аа, вот оно что, в каких-то случаях он все-таки не используется.. Ясно.

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

обычно такое меню выводится в шаблоне common/header.tpl, хотя как конкретно у вас меню выводится, неизвестно.

Как вы знаете в опенкарте есть система вывода миниатюр изображений. Указываешь длину и ширину и получаешь миниатюру. Типа такого вызова в контроллере: $thumb = $this->model_tool_image->resize('image.jpg', 200,200); Но сделано так, что если у тебя исходная картинка широкая, а надо получить узкую, или наоборот, то делаются поля (белые или прозрачные, в зав. от типа картинки, jpg или png) Для сравнения, в WP, где также есть подобная система, картинка масштабируется и урезается под нужные размеры. Поля не делаются.Вот иногда в опенкарте требуется именно чтобы не создавались поля. Миниатюры делаются в файле /system/library/image.php Там есть публичная функция resize, ее надо чуть подправить: public function resize($width = 0, $height = 0, $default = '', $fit = false) { if (!$this->width || !$this->height) { return; } $xpos = 0; $ypos = 0; $scale = 1; $scale_w = $width / $this->width; $scale_h = $height / $this->height; if ($default == 'w') { $scale = $scale_w; } elseif ($default == 'h') { $scale = $scale_h; } else { if ($fit) { $scale = max($scale_w, $scale_h); } else { $scale = min($scale_w, $scale_h); } } if ($scale == 1 && $scale_h == $scale_w && $this->mime != 'image/png') { return; } ... я добавил новый параметр fit, который по умолчанию false и все работает, как обычно. Если он true - поля не создаются, а просто обрезается лишнее.Также надо добавить этот параметр в файл /catalog/model/tool/image.php public function resize($filename, $width, $height, $fit = false) { И там внутри этой функции найти вызов $image->resize($width, $height, '' , $fit); и тоже добавить fit Таким образом, вызов в контроллере будет выглядеть так: $thumb = $this->model_tool_image->resize('image.jpg', 200,200, true); // если надо не создавать полей

аа, точно, не заметил. Ну это только в коде править.

только не category_id, а path_id

https://www.awesomescreenshot.com/video/1860545?key=55b877a3edb55b1294bf1562932d0a0a

https://prnt.sc/vqf3qp

Но в том, то и дело, что этот доп. индекс у меня решил все проблемы со скоростью. Собствено уже и кэш не нужен, все быстро открывается

я еще прикрутил кэш к этому делу. То есть, если считается для какой-то категории (только для нее, без учета всяких фильтров) тогда смотрим в кэш для этой категории, если есть - то не обращаемся к БД и берем из кэша. Если сохраненного в кэше по этой категории нет - делаем стандартный запрос к БД и сохраняем в кэш для этой категории. Я говорю о станартном кэше опенкарта: $this->cache->get $this->cache->set Но вот если надо почитать количество с учетом каких-то проставленных фильтров - вариантов может быть очень много, все не сохранишь, будь то в кэше, будь то в каком-то поле...

Как-то пришлось работать с магазином, в котором было много товаров, до 50к. И заказчик очень захотел, чтобы показывались количества товаров в разных категориях. В модуле category они обычно выводятся в скобочках. И есть возможность отключать это в Системе настройкой "Счётчик товаров в категории". Там еще предупреждение выводится, что если много товаров - будет тормозить. Проанализировал запрос, который делается при подсчете количества товаров в папке, phpMyAdmin (анализ запроса). Выяснилось, что он очень нерационально выполняется. Явно было недостаточно какого-то индекса. И точно, в таблице oc_category_path нехватало простого индекса по полю path_id. Там есть Primary по двум полям, но нужно было именно по path_id. Добавьте, у кого много товаров и тормозит. Мне помогло существенно.

Добрый день. Подскажите, если в CSV около 500 000 товаров и их надо импортнуть - ваш модуль сможет это сделать? Я слышал, не все модули могут так много импортить.

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

А в чем проблема? Столько уже разработчиков захотело сделать - а воз и ныне там? Я помню этот ваш проект на Fl.ru, уже наверное месяца два назад. И до сих пор никто не сделал???

Как вариант, можно в товаре "ABC-123" забить "ABC123" в поле товара "tag". Поиск ищет и по тэгу, поэтому будет находить в обоих случаях. P.S. Прописать в tag можно автоматом SQL-запросом. К примеру, из названия модели скопировать в tag: UPDATE oc_product SET tag = REPLACE(model, '-', '') Из названия товара если надо - потребуется LEFT JOIN oc_product_description и оттуда взять name.

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

Здравствуйте. Занимаюсь разработкой/доработкой функционала Опенкарт, в т. ч. и в админке. Работаю с данной CMS уже давно. Честность и порядочность гарантирую. Готов помочь в реализации Вашей задачи. Подобное уже осуществлял.

Скачал файл выгрузки. А как указать номер колонки для различный полей? Это не Эксель ведь. По экселю вроде понятно, а вот XML..