Артем Полторанин

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

Здесь нет никакой ошибки. Заголовок и описание вы ставите с помощью дополнительного модуля-надстройки seocontrol, этот модуль предназначается исключительно для SEO, а для SEO важно, чтобы при обращении по URL отдавались те или иные H1 и описания (т.е. при обновлении страницы). ------------------- При выборе фильтров обновляется только зона со списком товаров, именно такое поведение заложено в стандартную логику платформы. -------- Человек видит флажок в зоне фильтров - именно он и дает понять, что фильтр установлен.

Вынужден добавить технические подробности в данный вопрос, так как судя по всему никто из задававших данный вопрос им не интересовался. ----- В настоящее время модуль СДЭК работает по протоколу версии 1.5, для калькуляции используется метод, описанный в "п. 4.13.1. Расчет стоимости по тарифам с приоритетом" документации по API СДЭК. Данный метод на вход принимает список тарифов в порядке заданных вами приоритетов, а на выходе возвращает ID выбранного тарифа и одну цену доставки. Запрос к СДЭК - это не дешевое по времени удовольствие. Бомбардировать СДЭК запросами на калькуляцию для разных тарифов будет стоить - несколько секунд, а может и несколько десятков секунд (в зависимости от нагрузки серверов СДЭК). Этот метод мы не рассматриваем, так как он неприемлем с точки зрения итоговых параметров времени выполнения, так как следующий вопрос, который к нам поступит от профессионалов - "Как вы догадались до такого №%## механизма определения оптимального тарифа? И почему он требует 10 секунд для калькуляции." В ReadyScript предусмотрен универсальный механизм для решения таких проблем - он называется фильтрация отображения по зонам. Им можно пользоваться сейчас, просто нужно провести настройку в какие регионы, по каким тарифам вы желаете доставлять товары. Именно такое решение, что предлагает Идеальный пиксель - можно реализовать простейшим кастомным модулем, который будет обрабатывать событие формирования списка доставок. ------- Единственным корректным решением в данном случае может быть - это выполнение такого запроса к СДЭК, который бы возвращал нам сразу калькуляцию по разным тарифам. В протоколе 1.5 такого метода - нет. Возможно в новых версиях (2.0) протокола СДЭК такое уже есть, но для этого нужен совершенно новый модуль СДЭК. Это единственно верное с точки зрения оптимальности решение. ------ Не забывайте, что мы мыслим при разработке абстрактно (мы не кастом строим, а платформу). Для нас доставка - это объект возвращающий точную стоимость по входным параметрам - Заказ, Адрес. Именно доставка полностью ответственна за свою калькуляцию. Не совсем логично на движок сваливать пост-обработку полученных от модуля стоимостей.

Вы зря так думаете. Ряд крупных проектов на ReadyScript мы обслуживаем самостоятельно и сталкиваемся со всеми теми же проблемами, с которыми сталкиваются наши партнеры. У нас еще есть 5+ каналов получения информации от клиентов (форум, поддержка, сервис пожеланий, online-консультант, телефон, ...), по которым мы ежедневно получаем информацию. Просто мы разделяем платформу и кастомы. Любой крупный серьезный проект - это всегда платформа + кастомы. Тут не должно быть иллюзий. Именно поэтому на рынке существуют интеграторы, веб-студии. Хотя нам конечно тоже хочется, чтобы в платформе было побольше функций, чтобы кастомов было меньше, но к сожалению приходится выстраивать приоритеты. По основному вопросу темы, я ответил ниже.

Идеальный Пиксель, и здесь я должен пояснить по важному техническому моменту, на который вы не обратили внимание. В рамках модуля доставки все запросы идут через специальную прослойку ExternalRequest, который имеет всегда включенный внутренний кэш, то есть второй раз абсолютно одинаковый запрос никогда не поступает на сервер Службы доставки. Поэтому 2,3,10 одинаковых запроса всегда выполняются как один по времени и по сути. Совсем другое дело отправлять разные запросы, с разным tarrifList вы же именно это предлагаете.