Freimaks

Найден небольшой косяк в модуле: public function getCartTotal() { ... $end_total = 0; foreach ($totals as $total) { if ($total['code']!='total') $end_total = $end_total + $total['value']; } return $end_total; } В условии не хватает проверки $total['code']!='shipping'. Если такой проверки нет, то может случиться такая ситуация: сумма заказа не достигает той, что даёт право на бесплатную доставку. Покупатель выбирает постамат, сумма доставки плюсуется к заказу (и, например, общая стоимость становится больше пороговой для бесплатной доставки). Тут все правильно. А теперь если покупатель просто решит еще разок посмотреть постаматы и выберет какой-то из них (тот же самый или другой - не важно), то доставка становится бесплатной, ведь при новом расчете модуль прибавит и ту стоимость доставки, что уже фигурирует в заказе.

Доброе! А можно по-дефолту добавить в "Изменение стоимости доставки по регионам:" поддержку действий (+ и *)? if (($cart_total>=$start) && ($cart_total<=$end)) { $custom_price = $template_price_items[1]; $custom_action = "/"; // Ищем в $custom_price * или + $pos = strpos($custom_price, "*"); if ($pos !== FALSE) { $custom_price = substr($custom_price, $pos + 1); $custom_action = "*"; } else { $pos = strpos($custom_price, "+"); if ($pos !== FALSE) { $custom_price = substr($custom_price, $pos + 1); $custom_action = "+"; } } break; } После такого фикса будет работать такое описание региона: Московская обл. : 5000/+0, 0. Т.е. при заказе до 5к стоимость доставки равна стоимости, полученной от PickPoint, а дальше - бесплатно. Аналогично с умножением цены от PickPoint, например Московская обл. : 5000/*1.2, 0 (накидываем на стоимость PickPoint 20%).

Как вариант в модуле можно добавить обновление региона доставки в соответствии с выбранным постаматом. Я для себя добавил такой костыль (мне нужно только для России, поэтому в запросе к БД параметр country_id указан без использования переменных): $real_zone = $shipping_pickpoint_terminal_region; if (mb_strtolower($shipping_pickpoint_terminal_cityname, 'utf8') == "москва") { $real_zone = "москва"; } if (mb_strtolower($shipping_pickpoint_terminal_cityname, 'utf8') == "санкт-петербург") { $real_zone = "санкт-петербург"; } if (mb_strtolower($shipping_pickpoint_terminal_cityname, 'utf8') == "севастополь") { $real_zone = "севастополь"; } $query = $this->db->query("SELECT zone_id FROM " . DB_PREFIX . "zone WHERE name LIKE '%" . $this->TrimName($real_zone) . "%' AND country_id = 176"); if($query->num_rows) { $this->session->data['simple']['shipping_address']['zone_id'] = $query->row['zone_id']; } Дополнительно, чтобы в логах не было ошибок про DPMax и DPMin можно использовать такой фикс: $DPMax = $shipping_pickpoint_add_days; $DPMin = $shipping_pickpoint_add_days; if(isset($data['DPMax'])) { $DPMax += $data['DPMax']; } if(isset($data['DPMin'])) { $DPMin += $data['DPMin']; }

Вопрос с PageSpeed задавался не зря (он и ранее уже поднимался): на реальном сайте (не демо) просадки в этом сервисе будут достаточно серьезные. В любом случае придется заниматься оптимизациями, которые могут быть связаны как с функциональностью самого шаблона, так и дополнительно навешанных на него модулей, модификаторов и т.п. Например, вот мне не нужен Zoom на картинках товаров, я могу отключить сам эффект в админке, но JS и CSS для него продолжают грузиться и, пусть крайне незначительно, продолжают бесить Google (на самом деле можно дополучить от 2 до 5 баллов). Хотя этого можно избежать просто скорректировав revolution.ocmod.xml: if($data['zoom']) { $this->document->addScript('catalog/view/javascript/revolution/cloud-zoom/cloud-zoom.1.0.2.js'); $this->document->addStyle('catalog/view/javascript/revolution/cloud-zoom/cloud-zoom.css'); } В исходнике эти файлы подключаются вне зависимости от того нужны они или нет. Тоже самое касается опции "Выводить кнопки соц. сетей", которая далеко не всем нужна, но которая добавляет к скиптам яндексовский tag.js: <script src="https://mc.yandex.ru/metrika/tag.js" defer=""></script> Пусть он и отложено выполняется, но точно также может занижать оценки (Google может ругаться на время жизни его кеша). Ну а дальше сами владельцы магазинов начинают навешивать на сайт какую-нибудь Метрику от Яндекса, которая хоть с вебвизором, хоть без него отжирает кучу времени (на сколько я знаю обсуждается до сих пор, хотя Яндекс обещал выкатить какую-то оптимизированную версию).

Спасибо большое, помогло!

Всем доброе! Вопрос про пробелы уже задавали, но решения я тут не нашёл: при каждом сохранении изменений для каждого вида доставки к значению "Текст для нулевой цены" добавляется пробел в начале. В итоге значение может выглядеть так: " Бесплатно". На фронте все это игнорируется, но в админке как-то дико смотрится... ocStore 3.0.2.0, PHP7.3.

Почистите ещё кэш шаблона. Ну и не забудьте поменять в своем файле в самом низу перевод (это ни на что не повлияет, то как-то логичнее для вас будет): $_['entry_date_available'] = 'Дата поступления'; $_['column_date_available'] = 'Поступил'; К сообщению прикрепил проверенную сокращенную версию (она не меняет исходную сортировку по имени и добавляет только колонку с датой поступления). filter_products_by_date_available.ocmod.xml

Это поле date_available из БД. В принципе вы можете в любом текстовом редакторе заменить к примеру date_modified на date_available (тогда вместо даты обновления будет выводиться дата поступления).

Ocmod можно использовать без установки. Вы можете просто положить этот файл в папку system (если у вас какой-нибудь навороченный шаблон, то там уже может находиться целая куча подобных файлов). Плюс такого подхода - редактировать его можно без повторных загрузок, да и в базе он светиться не будет - если станет ненужным, то просто точно также удалите файл и пройдете шаги 2 и 3 из списка ниже. Поэтому можете поступить так: 1. Заливаем этот файл в папку system (она на том же уровне, что и admin, image и тп); 2. Заходите в админке в раздел Расширения -> Модификаторы и жмете сверху справа кнопку "Обновить"; 3. Заходите в админке в раздел Панель состояния, жмете сверху справа кнопку "Настройки разработчика" и очищаете Системный кэш (остальное можно не чистить).

Попробуйте вот этот вариант - у меня работает на 3.0.2.0. Что он делает: 1. Добавляет столбцы Добавлен и Обновлен в админке; 2. В качестве стандартной сортировки делает сортировку по дате добавления; 3. Добавляет в фильтр каталог товаров в админке возможность фильтрации по конкретному значению даты добавления и обновления. filter_products_by_date.ocmod.xml

В общем нашел я косяк. Немного неправильно настроил модуль anyCSV/XLS/YML и он прописывал в таблице product_to_category привязку к несуществующей категории, что в дальнейшем и ломало всю логику работы. Бонусом накатил фикс от @Otvet, чтобы починить canonical. За это ему отдельное спасибо (сайтмап от него тоже прекрасен). Что касается anyCSV/XLS/YML, то у меня еще возникла проблема с созданными производителями. Если в поддержке подтвердят, что это реально баг, то я выложу кусочек кода, который у меня этот баг пофиксил (хотя, наверное, пользователей плагина немного и это может вообще не актуально).

Всем привет! Что имеем: 1. ocStore 3.0.2.0, соответственно SeoPro идет из коробки; 2. Шаблон от OCTemplates; 3. Модуль импорта anyCSV/XLS/YML; 3. В настройках в разделе "Сервер" включены ЧПУ; 4. В настройках в разделе SeoPro включен как сам SeoPro, так и режим "ЧПУ товаров с категориями". Для всех товаров и категорий прописаны SEO URL. В итоге работа магазина выглядит так: 1. Категории отображаются как должны: mysite.com/cat/subcat. Точно также и в хлебных крошках; 2. Товары отображаются без категорий: mysite.com/product. В хлебных крошках так же категорий нет; Отключаем SeoPro, очищаем кэш. Товары начинают соответствовать заявленному виду mysite.com/cat/subcat/product. При этом ссылки на стандартные информационные страницы типа Производители выглядит стандартно для OpenCart: index.php?route=product/manufacturer, а добавленные мной - так как прописано в SEO URL (типа mysite.com/about). Долго копал в чем причина и так понимаю, что подобное поведение вызывается тем, что товары загружаются с помощью anyCSV/XLS/YML. По крайней мере другой причины я не нашел. К примеру, если товар добавить вручную, то все работает отлично, если пересохранить импортированный товар, то для него тоже все начинает работать на ура. В таблице seo_url все необходимые записи для каждого товара, категории и производителя имеются и в настройках Дизайн->SEO URL все они отображаются. И еще вопрос: это нормально, что в таблице seo_url при обновлении товаров (или производителей) вместо обновления записи происходит удаление старой и создание новой?

Обе штуки правятся в TPL шаблона. Телефон в header, а подпись внизу в footer. Оба файла тут: catalog\view\theme\basecart\template\common\

Ну как вариант поправить TPL для Header

Я не самый большой спец, но раз никто больше не ответил: проверьте конфликт JS. Скорее всего, что-то либо совсем не подгружается, либо подгружается, но криво.