Андрей Николаев

В Вашем случае есть 2 ограничения:
1) Если у Вас будет 2 пользователя с одинаковым именем, то их данные смешаются в одну кучу
2) Если немного изменить формат $users то будет значительно проще получить результирующий массив (не нужен будет первый цикл на ассоциативность)

/**
 * Шаг 1 - разворачиваем $users в плоский массив
 * Если есть возможность получить его сразу ассоциативным,
 * то это было бы лучше
 */
$usersAssoc = [];

foreach ($users as $user)
{
	$usersAssoc[ $user['id'] ] = $user['name'];
}

/**
 * Шаг 2 - выполяем группирующее преобразование наших $punch
 */
$result = [];

foreach ($punch as $time)
{
	if ( !array_key_exists($time['user_id'], $usersAssoc) )
	{
		// В punch есть массив, который относится к пользователю
		// о окотором мы не знаем
		continue;
	}

	$result[ $usersAssoc[ $time['user_id'] ] ][ $time['id'] ] = $time;
}


echo "<pre>";
var_dump($result);
echo "</pre>";

Эм.. а какой кейс это закроет?
А UE насколько я знаю, это заменяет все - и подход стандартизирован и действия и взаимоотношения.
В вебе нет такой проблемы - классы обычно запиливаются для конкретного ORM/DataMapper и где-то, даже есть свой скаффолдинг.

Эм... а почему в теме вопроса один вопрос, а в тексте другой? Это фишка такая спрашивать 2 разные вещи в одном вопросе?

Какая архитектура быстрее трёхуровневая или двухуровневая?

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

Почему трёхуровневая архитектура клиент-серверного приложения надёжней двухуровневой?

Я процитирую многоуважаемого sim3x

Кто сказал, что надежнее?

На мой взгляд, у Вас происходит путанница двух слабосвязанных возможностей системы.

С одной стороны, Вы говорите о НСИ (насколько я понимаю Нормативно-справочная информация), а с другой стороны о так называемом RBAC (role based access control).
Разложить можно следующим образом:
1) Есть пользователи, который с определенной стороны являются справочником, а с другой стороны предметом иденктификации пользователя в системе
2) Есть роль, которая складывается из совокупоности возможных действий в системе.
3) Пользователь может иметь несколько ролей и права пользователя считаются исходя из совокупонсти максимально доступных прав.

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

Приведу пример: есть у нас некая ERP в которой 300 сотрудников и 3 роли - "гость" (по факту может не существовать в системе), "сотрудник", "администратор".
Если мы всех 300 пользователей привяжем к роли "Сотрудник", а потом попытаемся ее удалить, то тут может быть несколько вариантов решения данной ситуации (разные системы применяют разные методы)

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

Что касается вопроса про справочники, то в общем понимании слова под этим подразуемевается в основном пользовательская информации справочного (внезапно!) характера. Т.е. эта информация не влияет на технический аспект работы системы, но напрямую завязана на бизнес-логику системы (все можно оспорить конечно же).
Например справочником может служить:
- Тип формы собственности (Государственная, Муниципальная, Частная и т.п.)
- Организационно-правовая форма (Товарищество, Общество, Акционерное общество и т.п.)
- Сфера интересов (IT, Сельское хозяйство и т.п.)

То есть любая информация представленная в виде списка.
P.S. В частном случае и пользователи и роли тоже являются справочниками.

1) Произведите очистку кеша. В 90% случаев это решает проблему.
Если доступ в админ панель не работает, удалите содержимое папок /bitrix/managed_cache/, /bitrix/cache/ и /bitrix/stack_cache/ вручную.

2) Проверьте настройки проактивной защиты - если на боевом сайте она включена.
Для этого придется подключиться к СУБД и вручную произвести зачистку данных модуля (радикально, но работает).

А эти варианты особо и не будут работать.
Можете попробовать универсальный синтаксис конечно, но не думаю что в этой части он работает.

$APPLICATION->SetPageProperty("title", "={$cur_city[$poddomen]}");

Что касается именно задачи, то обычно это делается так:
1) Разрабатываем компонент, ну например custo:header.meta
2) В компоненте проверяем условия (например через GetPageProperty), а так же доп. параметры.
Если по всем показателям нужно заменить - используйте конструкцию Lorem Ipsum . Если заменять не нужно - пропускаете.

Важный вопрос: Почему делать нужно именно так?
В Битрикс24 нельзя лишать пользователя возможности переопределять конкретные теги на страницах.
Лучше это все делать в одном месте, чем потом искать откуда появляется $cur_city и что такое $poddomen.
Да и к тому, же, нужно будет проходиться по каждой странице и смотреть что нет ошибок ли на других, а так - 1 компонент который целостно закрывает эту задачу.

Если Вы используете только товарный маркетинг то эта схема еще может прокатиться, но вот с правилами корзины это уже не прокатит.

Дело в том, что в товарном маркетинге (устарел), использовались реляции к товарам, а вот в правилах корзины уже нет.
Правила корзины применяются исходя из значений указанных в корзине (спс КЭП) и до момента формирования заказа их нет (т.е. нужно создать временный заказ, выполнить его просчет и Вы получите все товары, к которым применены скидки, но увы не поймете какие именно).

Если Вы не хотите работать с json, то почему вы не пробовали работать с ним как с строкой?

Немного непонятен Ваш вопрос.
По спецификации RSS они уже содержат ссылки, но Яндекс не формирует у себя новости - он содержит лишь предпросмотр и ссылки на сайты с оригинальным текстом. Т.е. при нажатии на ссылку, Вы перейдете на Яндекс, который перенаправит Вас на сайт с реальной новостью. И в RSS он уже отдает эту ссылку.

Для обоих случаев Вам поможет статическией метод \CSite::InGroup([11]), а так же условие показа пункта меню (если они конечно в меню)

Если Вы уверены что на входе будут только a-zA-Z0-9-=+- (похоже на base64) то можно упростить и не перекодировать, например так:

$uncomingString = 'W+I4zLZyeJDAhQMe33tYRcXC+Falj9baMfjJw5yOijaPNHDYcnNlRlTGm3rvA6cn2hXMmW4ZKEyTphwzNMQlOlnNiCHK2LLpJLgXK6JHKuTYeParwqCud5Vn2dZXpxctrQf8OkbCqF12u0GcBR2or2HFBrEV13Jd5YAX4bRbUBk=';


function forceUnicode( $str = '' )
{
	$result = '';

	for( $i=0,$length=strlen($str); $i<$length; $i++)
	{
		$result .= "\\u".str_pad(bin2hex($str[$i]), 4, '0', STR_PAD_LEFT);
	}

	return $result;
}

echo forceUnicode($uncomingString);

/*
Выведет: 
\u0057\u002b\u0049\u0034\u007a\u004c\u005a\u0079\u0065\u004a\u0044\u0041\u0068\u0051\u004d\u0065\u0033\u0033\u0074\u0059\u0052\u0063\u0058\u0043\u002b\u0046\u0061\u006c\u006a\u0039\u0062\u0061\u004d\u0066\u006a\u004a\u0077\u0035\u0079\u004f\u0069\u006a\u0061\u0050\u004e\u0048\u0044\u0059\u0063\u006e\u004e\u006c\u0052\u006c\u0054\u0047\u006d\u0033\u0072\u0076\u0041\u0036\u0063\u006e\u0032\u0068\u0058\u004d\u006d\u0057\u0034\u005a\u004b\u0045\u0079\u0054\u0070\u0068\u0077\u007a\u004e\u004d\u0051\u006c\u004f\u006c\u006e\u004e\u0069\u0043\u0048\u004b\u0032\u004c\u004c\u0070\u004a\u004c\u0067\u0058\u004b\u0036\u004a\u0048\u004b\u0075\u0054\u0059\u0065\u0050\u0061\u0072\u0077\u0071\u0043\u0075\u0064\u0035\u0056\u006e\u0032\u0064\u005a\u0058\u0070\u0078\u0063\u0074\u0072\u0051\u0066\u0038\u004f\u006b\u0062\u0043\u0071\u0046\u0031\u0032\u0075\u0030\u0047\u0063\u0042\u0052\u0032\u006f\u0072\u0032\u0048\u0046\u0042\u0072\u0045\u0056\u0031\u0033\u004a\u0064\u0035\u0059\u0041\u0058\u0034\u0062\u0052\u0062\u0055\u0042\u006b\u003d
*/

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

Расширение административного раздела доступно не во всех случаях.

Например, можно разработать собственные страницы для админки и на события обработки меню заменить их на свои. Или вы можете работать через JS (а в некоторых случаях и php) расширяя какие-то страницы через события, например OnAdminListDisplay.
Есть и легальные хаки - например кастомизация заказа в админке.

Замените
if (isset($brand)){
На
if ( !empty($brand) ) {
И еще:

$query = "SELECT * FROM products WHERE brand =  '".$_POST["category"]."' ";

Почитайте про SQL Injection

А зачем Вы вручную это делаете?
Начнем с того, что в php есть расширение php-soap, которому только скормить адрес wsdl и вызывать уже готовые методы.

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

Очень интересный и животрепещущий вопрос в мире Битрикса :)
Дело в том, что пока увы нормально никто так и не научился работать с системами контроля версий в Битриксе).

Традиционно не так много решений:
1) "Миграции для разработчиков" от Рябина Андрей marketplace.1c-bitrix.ru/solutions/sprint.migration

2) Migrato от Интерволги https://github.com/intervolga/intervolga.migrato пост в поддержку https://www.intervolga.ru/blog/projects/bitrix-dat...

3) Прочие кастомные автоматизированные решения миграций (например скрипт который после коммита запускает какое-то свое ПО)

4) Традиционный подход "ручками" (когда каждый записывает какие изменения внес и при переносе их все повторяют)

Увы, как мы не бились, с Битрикс24 пока не удалось ничего подружить - то отваливаются crm-статусы, то БП не отрабатывают (все-таки там тоже могут быть и параметры и константы и код), поэтому у нас работает подхо 3+4 (плохо, но что делать)