Алексей Бурлака

Выборку делать не через fetch() а через getObject()

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

В настройках сайта установлен ли правильный домен.
В настройках главного модуля установить куки-префикс, отличный от стандартного (нельзя использовать внутри точки — только символы и подчёрк).
Перенести хранение сессий в БД в проактивной защите.
Посмотреть — может там в настройках модулей настройки с часовыми поясами какие-то особые.
Проверить php-время на сервере и время базы данных (не редко сюрпризы там)

...ну или делать отладку, если ошибка железно воспроизводится.

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

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

Вот, какие ключи предусмотрены в системе для почтового события по смене статуса:

$arFields = Array(
	"ORDER_ID" => (...),
	"ORDER_DATE" => (...),
	"ORDER_STATUS" => (...),
	"EMAIL" => (...),
	"ORDER_DESCRIPTION" => (...),
	"TEXT" => "",
	"SALE_EMAIL" => (...)
);

Среди них нет данных по пользователю, соответственно сделать в лоб (прописав в шаблонах почтовых типов ключ #ORDER_USER#) не получится.

Однако, при отправке почтового уведомления непосредственно про смену статуса среди прочих срабатывает событие
OnOrderStatusSendEmail, которому одним из параметров передаются поля — указатель на $arFields:

foreach(GetModuleEvents("sale", "OnOrderStatusSendEmail", true) as $arEvent)
	if (ExecuteModuleEventEx($arEvent, Array($ID, &$eventName, &$arFields, $arOrder["STATUS_ID"]))===false)
		$bSend = false;

Вы можете подписаться на это событие и например поступить так:
1. Добавляете в почтовый шаблон статуса ключ #ORDER_USER#
2. При реакции на событие формируете нужное значение для #ORDER_USER# и дополняете ним $arFields

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

>>> bitrix:main.include
Отвечает за:
• включаемые области: для страницы (AREA_FILE_SHOW == page) , раздела (AREA_FILE_SHOW == sect)
• подключение файлов (AREA_FILE_SHOW == file)

У вас случай с подключением файла.
В файле компонента:
/bitrix/components/bitrix/main.include/component.php
отрабатывается else:


И раз папки include нет, выделенная строка даст $bFoundFile == false.
А значит ничего не подключится в результате вызова компонента.

Если же файл будет найден, вызовется шаблон компонента bitrix:main.include, а это просто инклуд:

Возможно так: создаём две разделённые папки, каждая из них содержит своё ядро.
В nginx в настройках location делаем разделение по урлам, прописывая разные
set $root_path ...
в зависимости от запроса?

По идее, у вас при чтении раздела
["UF_POSITION_USER"]["VALUE"]хранит ID записи хайлоадблока.

По нему нужно получить поле, которое хранит название должности.
На скриншоте не видно, предположим оно хранится в UF_NAME.

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

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

[1] => [ "UF_NAME" => "Лаборант-исследователь",
[2] => [ "UF_NAME" => "Стажер-исследователь",

). И тогда просто по коду записи, из любого места проекта получали бы должность. И чтобы этот кеш хранился «вечно», а перетирался только если добавлена/отредактирована/удалена запись хайлоадблока

Тыц

1. У раздела заводим пользовательское свойство.

В нём (на выбор, исходя из удобства) храним:
• символьный код, заменяющий всё, что после /catalog/;
• полный урл, который будет опубликован вместо урла /catalog/символьный_код/;
• параметры запроса, например ?sort=z-a&avail=no или якорь для лендинга #buildings.

2. В шаблоне вывода меню проверяем: если пользовательское свойство заполнено, — видоизменяем урл, публикуемый в пункте меню.

Если заглянуть в базу данных, Местоположения 2.0 — это фактически три таблицы.
Буквально на днях разгребал всё для распаковки на D7 под задачу.

Главный список — в таблице b_sale_location, которая фактически ОГРОМНАЯ куча местоположений, сваленных в одну кашу (страны, регионы, города, деревни и улицы).

Главные узлы:
--- Символьный код — колонка CODE. Если чистым запросом прочитать заказ и местоположение, мы нередко увидим не location_id, а location_code. Это не привязанный к почтовому индексу, строка вида "0000028023"

--- Родительство (например, город относится к области) указывается в столбце PARENT_ID
Он либо указан, либо ноль

--- Тип узла (например, город это, область или страна) указывается в столбце TYPE_ID
В таблице b_sale_loc_type - расшифровка в кодах:
* 1 COUNTRY
* 2 COUNTRY_DISTRICT
* 3 REGION
* 4 SUBREGION
* 5 CITY
* 6 VILLAGE
* 7 STREET


--- Глубина погружения (грубо говоря — ориентир, сколько родителей вверх) указана в столбце DEPTH_LEVEL (самый верхний узел в своей ветке имеет глубину == 1)

=====
В этой куче свой плюс: указав в заказе просто символьный код "00000705506" (CODE узла-улицы) мы тем самым, раскрутив цепочку вверх до DEPTH_LEVEL == 1 получаем абсолютно всё: от улицы до страны. Что в принципе и делается в текущей версии заказов.
=====

Теперь, когда есть вводная можете прикинуть её на свою задачу.

Вам нужно три выборки:
• первая — по узлам первого уровня ЛИБО соответствующим TYPE_ID (страна);
• вторая — те регионы, кто родителем имеет выбранную страну (если погружаться на регион);
• третья — те города, которые родителем имеют выбранный регион.

Как-то так =)

На одном проекте менеджеры тоже постоянно контакты ломали: там и карта и отзывы и вёрстка хитрая с телефонами и адресами...

Как вариант: всё, что должно быть отдано на редактирование вынести в инфоблок или хайлоадблок, пусть там редактируют, а на страницу не пускать.

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

Пример содержимого файла .access.php (который отвечает за доступы внутри папки) — здесь перечень файлов-включаемых областей, которым пользователям из группы №6 дан исключительно доступ на чтение:

<?
$PERM["sect_contacts.php"]["6"]="R";
$PERM["sect_map.php"]["6"]="R";
?>

Если до Битрикса дошёл процесс, он пишет ошибки в файл
/bitrix/modules/error.log

Чтобы он это делал, в файле
/bitrix/.settings.php
нужно переменную [ "exception_handling" ][ "debug" ] установить в значение true

1. Каждая лицензия по-умолчанию содержит разрешение на два сайта, но вместо покупки доп лицензий, можно докупать сайты (+1 или безлим):
https://www.1c-bitrix.ru/buy/cms.php#tab-sites-link

Так вы будете все данные держать в одной админке.

2. «Например чтобы в админке на одной странице было 5 полей (под каждый язык свое поле) И при заходе на сайта по геолокации битрикс показывает те поля, которые принадлежат этой геолокации»

Можно и так. Тогда будет использована одна лицензия и один сайт.

3. Можно гибрид из п.1 и п.2

В общем, есть варианты, как видите =)