Sergey Sidorov

Вот подробное описание возможностей ArrayHelper На мой взгляд, что-то подобное можно получить с таким вариантом:

ArrayHelper::map($array, 'link', 'status', 'user_id');

Не точь в точь, но близко по смыслу.

Обновите фреймворк (сам) до последней версии

Посмотрите в сторону $APPLICATION->GetCurPageParam

Попробуйте обернуть в следующий вид: '={$catalogPriceCode}'

Самый простой вариант сделать простой компонент (или класс подключенный через init.php тут как кому более верно и архитектурно) и в нем например по урлу страницы или какому-либо идентификатору выбирать нужные элементы и показывать. Предварительно конечно определиться с привязкой страниц/идентификаторов к содержимому инфоблока из которого планируется сделать вывод. Если последнее по какой-то причине невозможно, то как альтернатива можно сделать промежуточный маппинг и организовать нужную связь.

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

global $USER; 
echo '<pre>';
print_r($USER):
echo '</pre>';

и после она вам возвращает объект со следующими полями
Т.е. со всей информацией что есть в профиле.

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

Проще всего кастомизировать файл выгрузки, они расположены по пути /bitrix/php_interface/include/catalog_export/yandex_run.php|yandex_setup.php (если пользуетесь стандартной выгрузкой). Кастомизируете оба файла (называете иначе, но обязательно сохраните постфикс файлов: _run.php _setup.php).

Код формирующий выгрузку содержится в yandex_run.php. (в файле будет содержаться подключаемый файл из ядра, найдите его, и полностью скопируйте код его содержимого себе в кастомизированный файл <вашеназвание>_run.php) . Сам код получения свойств конкретного товара такой

$ipropValues = new \Bitrix\Iblock\InheritedProperty\ElementValues(
                        $arCurElem["IBLOCK_ID"], // ID инфоблока
                        $arCurElem["ID"] // ID элемента
                    );
$arElMetaProp = $ipropValues->getValues();

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

Документация по D7 (если вопрос про нее) располагается тут

Запрос выполняется стандартными средствами getList (), например:

$filterVal = array(
        'select' => array(
            'ID',
        ),
        'filter' => array(
            '=GROUP_ID' => $_REQUEST['REMOVE_GROUP']
        )
    );
$propID = RE\TemplatePropertyTable::getList($filterVal)->fetchAll(); //получаем массив всех данных

где RE\TemplatePropertyTable - описание таблицы базы расширяющее класс DataManager - TemplatePropertyTable extends Entity\DataManager (про это тут )

Если речь не про D7 - то (), упрощенно, нужно подключить ядро

<?php require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php"); ?>
<?php
CModule::IncludeModule("iblock"); //подключаем модуль инфоблоков

$arSelect = Array("ID", "IBLOCK_ID", "NAME", "DATE_ACTIVE_FROM","PROPERTY_*");
$arFilter = Array("IBLOCK_ID"=>IntVal($yvalue), "ACTIVE_DATE"=>"Y", "ACTIVE"=>"Y");
$res = CIBlockElement::GetList(Array(), $arFilter, false, Array("nPageSize"=>50), $arSelect); //делаем выборку
while($ob = $res->GetNextElement()){ 
 $arFields = $ob->GetFields();  
print_r($arFields);
 $arProps = $ob->GetProperties();
print_r($arProps);
}
?>

На самом деле плохой практикой (и то в ряде случаев это утверждение спорно) является перекрытие существующих свойств bootstrap заданных в указанных классах (просто потому что это меняет нативное поведение и делает его неожиданным). Блоку с уже присвоенными классами bootstrap можно назначать свои классы в случаях когда данные классы расширяют (а не перекрывают (опять же не всегда это правило)) набор свойств заданных элементу.

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