С момента как внедрили.
Да это было круто, что при выборе варианта фильтров страница не крутится на верх, но есть клиенты (интернет-магазины) которым вот нужно, чтобы после выбора крутилось на верх, по этому приходиться править js ядра.
Ведь не так сложно сделать у блока настройки нужен ли скрол или нет, а еще лучше у настроек фильтров.
Говорю сразу, что в “Подтверждённые баги” (с обещанием исправить за 45 дней) этот запрос не попадёт. А для “запроса по улучшению функциональности” настройка пока вырисовывается не очень ценная — слишком глубоко запрятанна и неочевидна для пользователей. Поэтому пока не понимаю, зачем её внедрять.
Но интересно, чем руководствуются клиенты, когда просят это поведение. Т.е. какую ценность им это даёт.
Мне кажется, как раз очевидна. Все подряд хотят или так, или иначе. Не скроллит - хотят чтобы скроллило. Скроллит - чтобы не скроллило. Ценность, которую оно им даёт - во-первых. магазины разные, число фильтров, товаров на страницах, их размер. Но что более важно - людям хочется чувствовать свой “вклад”, что это их решение. Потому как и в том и в другом варианте натыкаются где-то на магазин, который работает именно так как им нравится и хотят так же. И это даже находит логические обоснования, в каждом отдельном случае.
Для информации: если после фильтрации нажать на подсказку “N товаров найдено”, то происходит скролл к началу страницы.
Ведь не так сложно сделать у блока настройки нужен ли скрол или нет, а еще лучше у настроек фильтров.
“Добавить настройку” — это очень простое решение, но которое несет в себе потенциальные проблемы:
Конкретно по поводу добавления скролла для фильтров. Т. к. скролл был раньше в CS-Cart, то можно просто вернуть прошлое поведение при фильтрации:
js/tygh/product_filters.js
ajax_promise = $.ceAjax('request', url, {
result_ids: ajax_ids,
full_render: true,
save_history: true,
get_promise: true,
hidden: true,
caching: false,
obj: obj
});
на код:
ajax_promise = $.ceAjax('request', url, {
result_ids: ajax_ids,
full_render: true,
save_history: true,
get_promise: true,
hidden: true,
caching: false,
scroll: '.ty-mainbox-title',
obj: obj
});
Вот вот правок 1 строчка + сделать проверку настройки у блока фильтров где выставляется крутить или нет.
Вы видели настройки темы Юни? И там их еще мало, за-то каждый может настроить под себя продукт без призыва программиста к помощи, и меня как разработчика это очень радует, на юни1 оверайдов и хуков приходилось делать кучу, сейчас там все измеряется единицами и уже приближается к тому, что обновления темы у большинства будет без тестирования старых правок.
То есть вы переживаете о том, что разработчику будет сложнее работать, мне кажется важнее переживать, чтобы все же клиент мог удобно работать, кажется именно на этом основывался цс-карт не зря админке уже более 10 лет, а она все еще самая удобная в плане расположения и подачи информации.
Именно так. Но удобство подразумевает и простоту для клиента. Поэтому перед добавлением каждой новой галки и изменением поведения мы стараемся:
Например, недавно в модуле “Отзывы о товарах” появилась галка, которая решает, где показывать отзыв — в отдельной вкладке товара или над описанием. Почему она появилась:
А в случае с галкой, о которой идёт речь, мне пока видится так:
Скорее, мы переживаем о том, чтобы внимание разработчиков концентрировалось на задачах, которые реально усилят продукт для как можно большего количества пользователей.
Я согласен с аргументом @redrikshukhart про “свой вклад” и эффект от того, как настройка меняет поведение магазина. Собственно, поэтому мы и сделали галку для вариаций. Но не могу “кто-то хочет так, а кто-то иначе” назвать достаточным аргументом для таких решений.
P.S. В общем, функциональность такую не планируем, пока не будет обращения с реальным кейсом, почему в магазине какого-нибудь клиента такое поведение будет удобнее, чем текущее. Тем более раз возможность сделать это под себя и быстро всё-таки есть.
Кстати, а нет варианта фильтр товаров вообще в модуль вынести? Хотя, наверное, это просто не реально. Сам понял что спросил. Но в целом, это бы открыло ряд возможностей.
Надеюсь, также будет пересмотрен механизм именования вариаций в новом модуле обмена с 1С.
У меня, к примеру, есть понимание, что наименование товара на сайте (вариации как один товар) должно браться из названия ТОВАРА, а не названия ВАРИАЦИИ.
Аналогично, пока не понимаю большой ценности для среднестатистического владельца магазина от такого. Но почему-то кажется, что из-за этого много модулей переделывать придётся. Поэтому, навскидку, это не вариант.
Я так понимаю, речь о вот этой теме:
https://forum.cs-cart.ru/t/modul-obmena-neverno-imenuet-tovary/20593
Спасибо, что оформили в баг-репорт. В той теме мы обязательно ответим, когда до неё доберёмся. В этой теме у меня получилось ответить быстро, потому что я знал, что изменений скорее всего не будет. А в вашем примере с вариациями и 1С скорее всего что-то править понадобится 
А так как эта тема ушла в офтопик, я её закрываю. На первый пост ответ дан.