koder_1

Проще всего передать в параметр компонента свой параметр, например, 'CUSTOM_SHOW_BUTTON' => 'Y' и он будет доступен в template.php в $arParams['CUSTOM_SHOW_BUTTON']
Если это нужно в component_epilog.php то передать из result_modifier.php
Есть в битриксе урок как передать переменные из result_modifier.php в component_epilog.php

Кэширование можно также обойти например, через js, или есть хитрые техники в template.php выводить **BUTTON** статично, а в component_epilog его заменять на значение.

Компонент catalog.section.list выводит разделы, а свойства есть не у разделов, а у элементов.
Уточните задачу.

Вообще-то, у вордпресс архитектура почти аналогичная битриксу.
Вместо инфоблоков в вордпресс посты, а вместо свойств - поля.
Плагин Advanced Custom Fields (ACF) - сильно упрощает работу с custom fileds, которые в wp есть, но интерфейса для работы с ними нет.

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

У вас во-первых, урл страницы раздела /raspisanie-avtobusov/#SECTION_CODE#/
а урл страницы детального просмотра /raspisanie-avtobusov/#ELEMENT_CODE#/
при такой логике /raspisanie-avtobusov/aaa/ - это раздел с кодом aaa или элемент с кодом aaa ? Битрикс не может определить. Урл для страницы детального просмотра можно задать, например, так /raspisanie-avtobusov/#SECTION_CODE#/#ELEMENT_CODE#/

В комплексном компоненте новостей как-раз нет таких проблем и ссылки работают сразу, поэтому проще переделать на комплексный компонент.

Ну и в urlrewrite.php правила конфликтуют.

В 2005 -2008 годах была такая занятная традиция, каждая веб-студия, даже из одного программиста, писала свою цмс.
Для этого была необходимость, потому что существовавшие тогда движки не удовлетворяли хотелки клиентов, например по seo, только появилась мода на ссылки чпу к примеру, а в джумлах и вордпрессах того времени было с этим туго.
Ну и плюс стандартный тогда набор модулей, который ставился на сайт, не был реализован в движках, разнообразные календарики, модули опросов - маст хэв на сайте 2006 года.
С учётом также повальной моды на индивидуальные сайты, слово самописная CMS тогда вызывало восторги у клиента.

Сейчас тенденция наоборот. Все студии переходят на популярные CMS, большинство студий на Битрикс. Там и модулей готовых побольше и программиста искать легко, и интеграции с чем угодно, стандартные возможности движка вполне удовлетворяют хотелки типичного клиента, да и поддерживать сайт на популярном движке всем проще. Сейчас слово самописная CMS скорее показатель, что сайтом занимается "школьник", вчерашний студент с блеском в глазах и жаждящий освоить программирование, но не понимающий требования рынка и вызывает у клиента дикий ужас и желание убежать.

Но для опыта и прокачки навыков штука полезная.

Есть же пример из документации Битрикс

global $USER;
$arResult = $USER->ChangePassword("admin", "WRD45GT", "123456", "123456");

Имхо, эта функция сложная для использования, надо знать контрольную строку для восстановления пароля.

Проще

$user = new CUser;
$fields = array('PASSWORD' => 'Parol1', 'CONFIRM_PASSWORD' => 'Parol1');
$user->Update($ID, $fields);

Делайте свой шаблон пагинации скопировав шаблон в папку с вашим названием.

Вам можно в шаблоне catalog.section получать данные из $GLOBALS['arrFilter'] если у вас называется переменная фильтра $arrFilter
Такая же переменная $GLOBALS['arrFilter'] будет доступна вероятно и в section_vertical.php, section_horizontal.php

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

Многоязычность это в некотором роде копия сайта. Шаблоны компонентов и сайта реализуете через языковые файлы, все тексты заменяете на конструкции вызова языковой фразы.
Можете делать, например, один язык в папке en, а другой в папке fr.
Просто копируете туда все файлы, создаёте либо в каждом инфоблоке копии свойств под каждый язык, либо копии инфоблоков на всех языках.

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

Иначе можно зарезать пользователей, которые никакие не дубли, а просто используют похожий email.

Свойства торговых предложений, по которым идет выбор торговых предложений и так нагружены функционально.
Есть еще свойства, которые добавляются в корзину. Возможно стоит реализовать через них.

Вы просто для теста в форме задайте

<input type="text" name="recipes[]" value="1"><input type="text" name="recipes[]" value="2">

отправьте ее и посмотрите как формируется в get-строке такой параметр, а потом сделайте в вашей get-строке так же.

recipes=22&recipes=845 вот эта строка даст в $_GET только recipes = 845, более позднее значение ключа recipes затрет более раннее.

Не все так просто. Нельзя просто в js поменять цену и чтоб она попала в заказ. Цена формируется в php компонента, в js она только выводится. Копайте в сторону событий заказа, в обработчиках можно цену менять.

Если у вас каталог выводится, например, на странице /catalog/
то в файле /catalog/index.php в настройках компонента catalog задайте соответствующую цену по условию от выбранного города.

Решил задачу таким образом.
В событии onbeforepriceadd получаю нужную наценку, пересчитываю по ней цену и записываю в поле PRICE.

Есть еще идея варианта решения. Договориться, что пользователи будут заполнять только цену BASE. В событии OnPriceAdd проверять что добавлена базовая цена, добавлять цены всех типов с пересчетом цены. Такой способ не пробовал, должен быть рабочим.

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

Не совсем понятна конечная цель.
Если новое название предложения должно показываться пользователю в корзине, то достаточно изменить шаблон корзины.

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