tgarl

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

Если это будут 3 разных раздела никак между собой не перемешиваясь, то я бы завел 3 отдельных инфоблока. А то что будет у них одинаковый шаблон это вообще не играет роли. А вот если бы вам требовалось где-то выводить элементы вперемешку, тут другой вопрос, скорее всего бы использовал 1 инфоблок и 3 раздела.

Всё разобрался.
Со всеми этими редиректами и сертификатами. Итого.

1. проверяем сам сертификат внесены ли в него домен и www.домен, если чего-то не хватает добавляем, так как проверка сертификата главнее настроек nginx, редиректы работают, вот только вы это не видите пока не разрешите перейти без сертификата на страницу далее(последние обновления браузеров могут не разрешать этого делать у меня IE дает выбор, а хром нет)
если используется cerbot, то команда где перечисляем все нужные домены
certbot -d domen -d www.domen --expand
2. в основном конфиге оставляем

server {
       ...
        server_name домен;
       ...
}

а так же добавляем уже дополнительно редиректы для www

server {
	listen 80; #для http редирект сразу на https и без www
	server_name www.домен;
	return 301 https://домен$request_uri;
}
server {
	listen 443; #для https
	server_name www.домен;
	return 301 $scheme://домен$request_uri;
}

Судя по тому что у вас swiper-slide - значит используется библиотека слайдера swiper, вот она и добавляет остальные стили и классы, а так же делает клоны элементов. Это нормальное поведение таких библиотек. Посмотрите в сети её возможные настройки, чтобы более оптимально настроить под свои нужды.

вместо

LOBALS['arrFilterFav'] = array('ID' => [$_GET["ID"]]);

разбейте строку по запятой
= array( 'ID' => explode(',', $_GET["ID"]) );

Регистрация происходит в самом компоненте /bitrix/components/bitrix/sale.order.ajax/class.php, а не в его шаблоне.

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

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

По умолчанию нельзя, но можно скопировать в свое пространство имен компоненты и в них ввести обработку ваших значений. Для каталога такой вариант не очень, так как много где используются настройки именно те которые возможны. Но для новостного компонента вполне возможно пойти таким путем.
А можно еще больше упростить Использовать не комплексный компонент, а разбить его на простые и в правилах настройки адресов прописать свои настройки чпу и вызов страниц с этими настройками где как раз простые компоненты, а там просто отталкиясь от реквеста создать фильтр. В самих же компонентах для указания адреса брать не те адреса что в настройках, а свои.

Сумбурно получилось, но основное что хотел донести что варианты есть, но придется самому описывать все это.