Имеем инфоблок, в котором есть связанные с другими инфоблоками свойства.

Если в связанном инфоблоке заполнен Символьный код API, при компиляции сущности

\Bitrix\Iblock\IblockTable::compileEntity($iblockApiCode);

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

Если Символьный код API не указан, референса у поля не будет 🧼

#orm #референсы #цепочкасостоитиззвеньев

Иногда бывает так, что в режиме редактирования никак не можешь добраться до параметров компонента. Наводишь, а параметры компонента не появляются. Хотя на админ-панели вверху все компоненты есть в списке. Иногда помогает, если вызов компонента обернёшь в div. Иногда нужно поправить вёрстку. Сегодня я расковырял другой случай.

Приметы моей ситуации: если глянуть на список админ-обёрток для каждого компонента, они будут с одинаковой нумерацией.

ТЛ;ДР: из-за большой вложенности компонентов система нумерации Битрикса путается и даёт сбой.
В моём случае вложенность четвёртого уровня вызывала это. Уменьшать вложенность или править ядро 🤓.

Нырнём вглубь.

Как формируются админ-обёртки

Нумерация слоёв управляется методами

\CEditArea::IncludeStringBefore
\CEditArea::IncludeStringAfter

За то, какой уровень мы сейчас наращиваем, отвечает бегунок $this->includeLevel. Цепочка номеров (можно представить как горизонтальный барабан из дисков с цифрами): переменная $this->includeAreaIndex. При наращивании уровней вложенности компонента бегунок смещается вправо по барабану, при уменьшении смещается влево.

Если у нас публикуется первый компонент, бегунок смещается на первый диск барабана (элемент массива) и крутит его на одно деление с каждым новым компонентом. Соответственно компоненты "в корне" будут с номерами: 1, 2, 3, ...

Каждая вложенность компонента наращивает хвост к текущему уровню и формирует цепочку счётчиков. Если у нас например четвёртый компонент на странице (номер 4), вложенный в него компонент получит код 4_1 (при вложенности бегунок смещается вправо, становится на второй диск барабана (элемент массива) и начинает крутить его). Три компонента в компоненте с номером 4 получат номера: 4_1, 4_2, 4_3 (бегунок на втором диске, крутит его).

На вложенности четвёртого уровня цепочка будет состоять из четырёх звеньев, например: [4, 2, 1, 1] и такой компонент должен получить номер 4_2_1_1.

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

Что мы ожидаем, когда смещаемся с четвёртого уровня на первый? Что цепочка была 4_2_1_1, а стала 4.
Что происходит на самом деле? Цепочка так и остаётся 4_2_1_1.

Если представить это в виде массива:

[
    0 => 4
    1 => 2
    2 => 1
    3 => 1
]

Теперь следим за руками.

Размещается следующий компонент (! или старт рабочей области шаблона сайта).

Метод \CEditArea::IncludeStringBefore увеличивает счётчик первого диска на барабане: был 4, стал 5 и делает unset второму диску.

В виде массива:

было:

[
    0 => 4
    1 => 2
    2 => 1
    3 => 1
]

стало:

[
    0 => 5
    2 => 1
    3 => 1
]

Так как бегунок на первом уровне (цепочка строится от начала барабана до бегунка), компонент (или старт рабочей области шаблона сайта) получает номер "5".

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

Ожидаем:

[
    0 => 5
    1 => 1
    2 => 1
    3 => 1
]

...в реальности (особенность пхп):

[
    0 => 5
    2 => 1
    3 => 1
    1 => 1 <----- !!!
]

Компонент получает номер 5_1, что соответствует ожиданиям, хотя массив уже имеет неверную структуру.

Публикуется следующий компонент. Бегунок диску с номером "1" накручивает счётчик. и вот что получается:

[
    0 => 5
    2 => 1
    3 => 1
    1 => 2 <----- !!!
]

... но номер строится путём отрезания (array_slice) от массива первых двух номеров. И второй компонент вместо ожидаемого 5_2 получает снова номер 5_1. И так далее.

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

В моём случае я добавил в ядро функцию-сортировщик, чтобы массив на сборку номера уходил с ключами в правильном порядке:

[
    0 => 5
    1 => 2 <--
    2 => 1
    3 => 1
]

#битрикс #крутибарабанправильно #компоненты #режимправки

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

Отредактировать фото, сгенерировать фото, создать видео-короткометражку с участием любимой игрушки младшей дочери — это развилось уже до такого уровня, что мне от момента, когда возникла идея и до результата нужно от всего нескольких минут до всего нескольких часов (в случае с мини-мультиками). И это на расслабоне и на кайфе. Без мучительного поиска инструментов и сложного стека. В основном, с лингвистическими затратами (мат от непослушных нейронок — это тоже лингвистика, теперь она органическая часть процесса =). Вот ещё год назад — не. А сейчас, где-то с лета, с НаноБананами и Вео-со-встроенной-озвучкой — прям вау и много сердечек (таких, которые девчата составляют скрещением кончиков большого и указательного пальцев) ❤️❤️❤️❤️❤️

P.S.: ...и да, заглянул во внутренности сайта и увидел все письма, которые вы написали и которые не отправлялись мне из-за не настроенного крона с крон_ивентс. Сколько же там паутины было 🤪. Когда много работы, перестаёшь следить, прибираться и проветривать 🪓

#нейронки #душевное