Думаю все дело в том, что вы вносите изменения в шаблон, который находится в модуле, а на сайте у вас используется тема не default.

Вам нужно вносить изменения в шаблон /ВАША ТЕМА/moduleview/catalog/product.tpl
А еще правильнее, создавать на его основе  /ВАША ТЕМА/moduleview/catalog/product.my.tpl

В этом случае при любом обновлении ваши изменения не будут исчезать.

в Catalog\Controller\Front\ListProducts в методе init есть событие init.api.catalog-front-listproducts

В обработчике у вас есть переменная, ссылающаяся на этот контроллер ListProducts

Вы можете перехватить объект запроса на выборку товаров:

в handlers.inc.php вашего кастомного модуля:

public static function initApiCatalogFrontListProducts($controller) {
    $request = $controller->api->queryObj();
    //Тут можно делать что угодно с запросом, например добавить JOIN и уточнить секцию SELECT
}
Ярослав пишет:

Как раз пришлось реализовывать индивидуальные цены для товаров.
40 колонок цен со скидками  на товары уже существовали на базе стандартного справочника цен (причем есть товары, где скидка не должна превышать определенный процент).
Но захотели создавать цены в разрезе брендов, категорий и отдельных товаров. При этом настройку делают на стороне 1с.
Уговорить  реализовать скидками в корзине не получилось.
В итоге сделал модуль с отдельной таблицей индивидуальных цен (товар-пользователь-цена). При расчете цены товара сначала выборка делается из этой таблицы. В таблицу заливаю данный из csv файла с помощью LOAD INFILE, поэтому проблем с синхронизацией нет. Файл формируется на стороне 1с сразу с рассчитанными ценами для клиента. Попадают только товары, затронутые скидкой. Обычно из около 300-500 для клиента.
Все это касается только отображения цены.

Очень здорово, что вы не побоялись ввязаться в эту крайне непростую задачу.
Насколько я понимаю, вы добавляете join вашей таблицы во время выборки товаров, чтобы перекрыть цены из xcost?

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

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

Одна из проблем - это был объем такой таблицы, если на сайте 10 000 товаров, 1000 пользователей и 2 типа цен, то это уже 20 млн. записей. JOIN такой таблицы даже с индексами будет довольно дорогой по ресурсам. И это я привел очень скромные параметры - 10k товаров и все с одной комплектацией и без доп.унификаторов.

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

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

Вот я кстати хотел бы немного рассказать о незрелости технологий пока еще для динамического ценообразования.

Когда речь идет о ценах, всегда нужно помнить, что у цен бывает:

1. отображение
2. сортировка по цене по возрастанию (в списках)
3. фильтрация по цене (в списках)

Как вы понимаете сортировка и фильтрация должна оперировать полным набором данных, то есть если мы заходим в категорию, где 5000 товаров, то программа должна посмотреть на все 5000 товаров и выстроить их по возрастанию цены и вернуть в итоге только,например, первые 20 - что соответствует одной странице данных.

На случай, если кто-то из читателей не знает, то пагинация нужна исключительно с технической точки зрения, чтобы не нагружать память backend'а, браузера клиента объемом HTML, сеть гигантским объемом передаваемых данных. Пагинация - это необходимость.

Сейчас п.2, п.3. делает на своей стороне БД, так как RS только оперирует колонками цен. У юзера может быть установлена заранее подготовленная скидочная колонка цен. Это обеспечивает работоспособность всех функций и скорость работы.

Мы считаем, что в любом магазине должно быть ограниченное число колонок цен и оно НЕ должно быть равно числу пользователей. Магазины не понимают, что когда у них станет 2000 или 5000 или 10 000 клиентов вести индивидуальный порядок расчетов - невозможно. Крупные магазины всегда стандартизируют понятия Колонка цен 1 .... Колонка цен 10, вспомните Юлмарт. И все клиенты работают именно по какой-то колонке цен, а не имеют все разные пляшущие цены.

Для более гибкой политики - существует бонусная система и (внимание!) - бонусная система - это то, что в корзине или в карточке товара (как подсказка), а не в списках товаров в категории цены сразу с учетом ваших бонусов. Это очень важно!
Слой расчета бонусных скидок он чисто косметический и выполняется поверх уже отобранных из БД товаров. Соответственно скидки не могут учитываться во время фильтрации и сортировки.

-----------------------------------

Теперь о незрелости технической. К сожалению, реализовать динамическое ценообразование возможно (в наше время), только если вешать обработчики цен на стороне PHP, а соответственно сортировку и фильтрацию нужно будет также обеспечивать силами PHP, ну и самое главное, из БД в этом случае нужно получать не одну страницу товаров, а ПОЛНЫЙ набор данных.

Все это приведет к тому, что сайт будет катастрофически сильно тормозить.

Динамическое ценообразование предполагает, что колонка цен в БД - динамическая и она зависит от текущего юзера, от его прежних заказов, от категории продукции и возможно еще очень много от чего. В итоге нужно дождаться таких технологий, чтобы в БД в качестве колонки можно было объявить целую программу (callback), которая должна выполняться максимально быстро, чтобы не пострадало время выборки.

Пока удобной технологии для этого мы еще не нашли, поэтому мы разделяем понятия:

1. Типы цен - это то, что работает быстро, поддерживает сортировку и фильтрацию.
2. Скидки, бонусные программы - это то, что клиент увидит в корзине. Скидки могут быть сколь угодно сложные.

---------

Решил написать этот пост, так как мы стали получать много заявок, на тему "хотим, чтобы клиенты сразу везде и повсюду видели все цены с учетом своих скидок", но так, к сожалению, пока невозможно с обычным Mysql.

Daniel пишет:

К примеру описание товара в МойСклад заливается в RS в Краткое описание

Это в ближайшем обновлении будет починено добавлением опции в настройках модуля Обмен данными.
Почему-то Мой склад описание передает в реквизите "Полное наименование", что весьма и весьма необычно.

Андрей, принял информацию, спасибо!

Уважаемые пользователи, разработчики!

Давно мы не получали обратную связь!
Расскажите как у вас дела? Как поменялись ваши продажи после COVID?
Что на ваш взгляд в ближайшее время будет наиболее востребовано в online продажах?

Все ошибки, которые мы наблюдали на текущий момент, которые связаны с sameSite были связаны с внешними скриптами, то есть ошибки на их стороне. (Например яндекс метрика)

Если у вас есть подробное техническое описание именно на нашей ошибки, напишите.

109

(4 ответов, оставленных в Вопросы по работе с системой)

Такая ошибка может возникать только из-за старых js в кэше браузера. Что-то недоочистили 100%. Возможно не выбрали За весь период.

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

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

Думаю, без профессионального программиста переделать логику оформления заказа не получится.

Правило построения пути к шаблону такие:

Абсолютный URL:

%ИМЯ МОДУЛЯ%/ПУТЬ К ШАБЛОНУ ОТНОСИТЕЛЬНО ПАПКИ VIEW.tpl

Пример:
%users%/register.tpl = /templates/ТЕМА/moduleview/users/register.tpl или /modules/users/view/register.tpl
%users%/notice/touser_register.tpl = /templates/ТЕМА/moduleview/users/notice/touser_register.tpl или /modules/users/view/notice/touser_register.tpl


------------

В {moduleinsert} можно также указывать путь к шаблону относительно папки /view модуля, например

{moduleinsert name="\Menu\Controller\Block\Menu" indexItemplate="blocks/menu/catalog_menu.tpl"}

В этом случае путь к шаблону будет равен /templates/ТЕМА/moduleview/menu/blocks/menu/catalog_menu.tpl или /modules/menu/view/blocks/menu/catalog_menu.tpl

Ярослав пишет:
   /**
     * Возвращает подготовленную для поиска likePlus строку
     *
     * @param string $query
     * @return string
     */
    protected function prepareLikePlusString($query)
    {
        $config = ConfigLoader::byModule('search');
        $dis = preg_split('//u', html_entity_decode($config['search_type_likeplus_ignore_symbols']), -1, PREG_SPLIT_NO_EMPTY);

        return str_replace($dis, ' ', mb_strtolower($query));
    }

Уважаемые разработчики, подскажите, пожалуйста, почему замена идет на пробел, а не просто вырезается символ?
У меня с пробелом артикулы, маркировку не ищет. В поле indextext данные идут слитно, но при поиске тире, например, заменетс на пробел и поиск не работает.
Ставлю

   return str_replace($dis, '', mb_strtolower($query));

все замечательно работает


Суть опции - search_type_likeplus_ignore_symbols, указать символы, которые будут считаться разделителями слов. Поиск like+ все равно идет по всем словам.

Эта опция не должна формировать новые слова. В случае разделителя ''[пустая строка], Редискрипт будет заниматься формированием новых слов из кусочков других слов.

Плюсом является наглядность при просмотре базы, что и как там сформировалось.

Уважаемые клиенты!

Публикуем график работы на майских праздниках 2020.

С 1 по 5 мая - мы уходим на выходные дни.
С 6 мая мы работаем как обычно с 10:00 до 19:00 по МСК.

риза пишет:

здравствуйте.как могу заказать пряжу в казахстан

Мне кажется вам быстрее ответят, если вы спросите на сайте mybobbin, а не тут.

Ярослав правильно пишет, нужно использовать транслитерацию. Она помогает SEO, немного ключевиков в URL добавляет, а также полностью избавляет от вопросов с автоинкрементными номерами.

Сбрасывать счетчик первичного ключа - неправильно и некорректно, в других таблицах может что-то остаться, что будет ссылаться на "другой" товар. Единственный выход - это очищать кучу таблиц. По сути это сравни с обычной переустановкой всего ReadyScript.

Джордж пишет:

Здравствуйте. Так получается вывести количество товаров на странице категории.

{$category.fields.itemcount}

А как сделать, чтобы там же, при изменении фильтров, количество товаров менялось?

-------

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

Я бы не рекомендовал вам этого делать. Обычно делают расчет количества товаров с учетом фильтров только в рамках текущей категории и выводят это число возле фильтров.

117

(2 ответов, оставленных в Вопросы по работе с системой)

Если речь идет о простом сокрытии значений характеристики в фильтре, которых нет в наличии у комплектации, то для этого нужно включить опцию "Учитывать остатки комплектаций товаров в фильтрах при использовании многомерных комплектаций" в настройках модуля Каталог. И обязательно использовать многомерные комплектации, хотя бы с одним параметром.

-----------

Если имеется ввиду другая задача. Формировать фильтр по значениям характеристик комплектаций - логически невозможно.

Фильтрация происходит именно по объекту товара, потому-что пользователь в списках видит всегда только основную комплектацию товара всегда (то есть сам товар), соответственно характеристика товара должна описывать все возможные значения его комплектаций.

Если товар бывает в размерах S,M,L,XL.
То должна быть списковая характеристика "Размер товара" со значениями S,M,L,XL.

А у каждой комплектации задана хар-ка "Размер товара" только с одним значением S или M или L или XL

118

(4 ответов, оставленных в Вопросы по работе с системой)

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

Про push в каком приложении идет речь, кто и где изменил статус.
Распишите весь сценарий подробнее пожалуйста. Кто меняет статус и кто уведомляется?

Алексей пишет:
admin пишет:

В css есть order, дописывайте произвольные стили к секциям и все.
В вашем css предусмотрите media query для применения нужного order при необходимых разрешениях.

Спасибо!
тогда за что отвечает поле "порядок" в конструкторе?


Хороший вопрос.
Сейчас проверили - это поле имеет смысл только при использовании bootstrap4. Наша стандартная тема Flatlines сделана на bootstrap3, в bootstrap3 классов для reordering еще не было.

121

(1 ответов, оставленных в Вопросы по работе с системой)

Добрый день!
В каждой теме оформления стикеры реализованы по разному.

------

Например:
В Классической теме, отображается картинка спецкатегории в качестве стикера.
В Детской теме идет заранее заложенная дизайнерами картинка "Новинка", а выводится она, когда товар состоит в спецкатегории с алиасом "new".
В Современной теме выводится просто название спецкатегории, если у спецкатегории установлен флаг "Показывать как ярлык у товаров"

В css есть order, дописывайте произвольные стили к секциям и все.
В вашем css предусмотрите media query для применения нужного order при необходимых разрешениях.

123

(2 ответов, оставленных в Вопросы по работе с системой)

Воспользуйтесь бесплатным модулем в маркетплейсе "Редактор ORM объектов".
http://marketplace.readyscript.ru/addons/ormeditor/

Добавьте к объекту Catalog\Model\Orm\Dir поле Картинка (Например с именем banner_image). Так вы сможете загружать картинку в любую категорию.

А затем задействуйте данную картинку в нужном месте шаблона, обращаясь к ней так:

<img src="{$category.__banner_image->getUrl(1024, 500)}">

В итоге, вам не нужен модуль "баннеры" вообще.

124

(1 ответов, оставленных в Вопросы по работе с системой)

Вы абсолютно некорректно используете конструкцию $router->getUrl(), в первом аргументе должен идти ID маршрута (route).
https://readyscript.ru/dev-manual/dev_routing.html

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

У нас есть механизм, запоминающий путь попадания пользователя в карточку товара.

Логика этого механизма следующая:
1. Если пользователь попал в карточку товара через одну из категорий товара, то выбирается она
2. Если пользователь попал в карточку товара напрямую (из поисковика, например), то выбирается основная категория

Данный механизм используется в хлебных крошках. Вы можете просто воспользоваться последней секцией из хлебных крошек на странице карточки товара.


{$bc = $app->breadcrumbs->getBreadCrumbs()}
{$last = end($bc)}
<a href="{$last.href}">Назад</a>