Михаил

как вариант надо перебирать привязанные разделы и вытаскивать с каждого элемента изображения, НО
это некорректное решение с точки зрения нагрузки.
почему бы не создать свойство Фото с типам файл в инфоблоке "Туры", сделать его множественным и настроить под изображения.
в таком случае вы сразу сможете получать массив файлов несколькими способами без лишних запросов и не занимая кучу не нужных таблиц.
инфоблоки не рентабельно создавать под единичные элементы, например под изображения, для этого есть доп.поля или highload-блоки, а иногда эффективнее заводить свои таблицы, но это уже когда middl'ом станите.
каждый инфоблок, в который входит разделы, элементы, доп.свойства, занимает несколько таблиц бд, запросы получаются огромные, все обработки у него тяжеловатые по весу.

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

столбец IBLOCK_SECTION_ID не содержится в b_sale_basket
надо через join доставать
соответственно добавляем runtime

'runtime' => [
'ELEMENT' => [
            'data_type' => '\Bitrix\Iblock\ElementTable',
            'reference' => ['=this.PRODUCT_ID' => 'ref.ID'],
            'join_type' => 'left'
        ],
]

а в фильтр добавляем
'=ELEMENT.IBLOCK_SECTION_ID' => 114
или в getMap корзины вроде есть PRODUCT связывающий с товаром, можно попробовать в фильтре без runtime
'=PRODUCT.IBLOCK_SECTION_ID' => 114

наверное order_ajax.js а не *php
вообще sale.order.ajax самый убогий и кривой компонент в Битриксе, по хорошему его переписывают, под себя, при этом сокращая объем в десятки раз.
если же менять верстку в дефолтном, то надо примерно так же курнуть как разработчик этого компонента, и лезть в js, добавлять класс с помощью addClass а в style.css описывать, думаю и местами поля там поменять можно, при условие если разобраться где что описано)

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

CNextCache::CIBlockSection_GetList(array('SORT' => array('NAME' => 'ASC'), 'CACHE' => array("MUL.....

а возможно не получится, все зависит от метода
в крайнем можно отсортировать массив перед выводом через usort, но это уже костыль, хотя и рабочий вариант

во-первых, это событие со статичными свойствами, т.е. не универсальное. ты эти свойства завел? они точно имеют указанные ID?
во-вторых, а где ты пытаешься проверить этот код? ты добавил этот обработчик события хотя бы в init.php?
в-третьих, учись делать дебаг, Битрикс тебе укажет что именно не работает.
а вообще судя по вопросу, рекомендую начать изучение Битрикса с более легких вещей, что бы понять структуру и логику, тогда не будешь называть обработчики сниппетами, и такой функционал сможешь сам написать под свой проект.

похоже что js ядра что-то перебивает, попробуй отрубить скрипты подключенные в шаблоне поочередно

вот здесь неплохо описаны функции корзины, самое необходимое, остальное можно по документации посмотреть.

Сейчас эти запросы больше будут полезны в Яндекс Директ)
Тебе дали толчок, что бы вкинул деньги в Яндекс)
Как бы вымогательно не звучало, но по другому повысить трафик сегодня тяжело)

если обращение напрямую к файлу, то параметр надо засунуть в скрытый input type=hidden
есть еще пару вариантов аякса:
1. обратиться к тойже странице где установлен компонент
2. если 1-й вариант не подходит(например на странице вызываются несколько компонентов, и построить структуру обработки запросов сложно), можно все аяксы пускать на один файл (я обычно кидаю его в /include/ajax.php) и в нем исходя из запроса вызывать необходимый компонент, так можно обрабатывать запрос на уровня ядра компонента, очень удобно если обработка аякса почти идентична обработки самого компонента.

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

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

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

сразу отмечу неправильное видение Битрикса:

проблема в компоненте bitrix:catalog*. По сути весь интернет магазин завязан на нем и поддерживает он только один инфоблок

стандартный компонент - это контроллер, который показывает возможности работы с API Битрикса (модулями).
минус стандартных компонентов: они сделаны под различные задачи, т.е. параметров там много, каждый параметр, это объем данных и обработка. итоговый массив данных содержит много не нужной информации.

Можно создать разделы в ручную, но еще кучу компонентов завязано на этом компоненте.

Компоненты завязаны, когда они являются комплексными. т.е. в одном компоненте вызывается другой. Ничего не мешает вызывать компоненты по раздельности.

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

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

в ручную делать костыли?

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

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

1. Посмотрите все настройки, правильно ли выставлены слеши site.url/docs/razdel-1/ и site.url/docs/razdel-1 это разные ссылки
2. docs убрать можно, для этого необходимо будет поиграться с urlrewrite.php ручками, а не стандартными настройками, при этом разобравшись и прописав правильные права первый вопрос решится сам собой.