Настройки поиска (Страница 5 из 42)

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

Daniel, в облаке происходят автоматические обновления, когда мы их выпускаем.

Автоматические обновления - не могут снимать галки в настройках, так как данные БД - не трогаются, только структура БД обновляется.

Если вы модифицировали системные шаблоны не по инструкции: https://readyscript.ru/dev-manual/dev_t … tends.html
То абсолютно все изменения будут возвращены в исходное состояние при обновлении.

Ярослав, добрый день!

Насколько мы понимаем, какой-то из компонентов Битрикс24 некорректно работает, если видит переменную global (была такая информация от одного клиента). Данная переменная необходима для работы ReadyScript, она обеспечивает трансфер в JS некоторых переменных из PHP. Это имя никем не зарезервировано и ее использование не запрещено.

--------

И на наш взгляд встраиваемые скрипты не должны зависеть ни от каких глобальных переменных.
Нужно писать в Битрикс24 по данному поводу. Ведь любой другой скрипт чата работает без проблем.

Добрый день!

{$product->getUnit()->stitle} - выведет единицу измерения, например кв.м.

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

Альтернативный вариант - это только использовать Мегамаркет и представлять магазины как филиалы.

Это настройка атрибута rel, туда можно добавить элемент в список, так как у TinyeMCE есть такой параметр rel_list
Но дописывать data-fancybox="gallery", оно не будет ) Возможно для этого нужно будет подключить какой-то плагин к tinyMCE.
-------------
Возможно fancybox можно инициализировать и на rel="lightbox", просто это должно быть явно прописано в JS, где fancybox инициализируется.

в 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
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---------

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

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

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

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

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

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

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