Александр Маджугин

нужно проверить наличие галочки в настройке свойства

и закрепить поле описания у свойства в элементе

Скорее всего проблема в имени файла.
Если ранее заходили, то браузер закеширует изображение.

Добавьте к имени файла ?p=1

Или нажмите ctrl+f5

На псевдоэлементы нельзя повесить события, они не относятся к DOM.
Добавьте вместо :after обычный элемент и на него повесьте событие.

Привет. Ну сначала хотя бы в инструментах разработчика. Вот твоя ошибка



Я так понял он не может найти элемент с id "catalog-ajax" . Но это все на первый взгляд)

1. Создай доп. свойство
2. Скриптом пробеги по всем товарам и присвой нужное значение или открой по очереди все товары и просто сохрани.
(Новым товарам свойство будет добавляться автоматом.)

Но ведь почему-то разработчики Битрикса решили от него отказаться?

Они не "решили отказаться", они его архитектурно еще не сделали. Элементы инфоблоков это не только запись в таблице это еще и свойства, которые могут хранится в двух вариантах, так что это вовсе не так просто.

Выходит нужно использовать старый CIBlockElement::Add() без вариантов?

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

Есть какой-то аналог Batch Processing от Doctrine?

Аналогов нет, но и операция не такая уж частая. Есть потребность в таких объемах - обычно либо это сторонние каталоги (цены, наличие, свойства и т.п.) и тут без CIblockElement::add не обойтись, либо своя таблица (а там уже что хочешь, хоть sql)

вполне законно.
не законно – использовать найденные уязвимости.

хотя, в этой стране, термин "законность" весьма юмористичен.

Для проверки чистой скорости сети передача файлов с винта на винт не подходит, вы можете упираться в пропускную способность жёсткого диска.
Используйте специальные утилиты, например, iperf.
Если iperf тоже покажет 100 Мбит/с, то надо смотреть в каком режиме работают сетевые карты, не включен ли на них режим принудительного ограничения скорости, проверять разводку кабеля на соответствие стандарту.

То что вы написали нельзя приравнять к опыту работы с фреймворком. Вы занимались доработками готового продукта, т.е. системы управления сайтом и натяжкой дизайна в шаблоны.
Чтобы ответить, что работал с bitrix framework, вы должны как минимум иметь следующий опыт:
- разработка собственных модулей для проектов, как с новым функционалом, так и с функционалом расширяющим возможности продуктов битрикс.
- наличие разработанных собственных бесплатных или платных модулей на маркетплейсе
- разработка собственных решений

Самый простой способ отловить этот баг - это добавить в error_log:

1. Длину $some_var (скорее всего, этого будет достаточно)
   
2. Код каждого символа. (Здесь и раскроется парадокс). Должно быть: 109 97 103 105 99
   

Закон дырявых абстракций

Из-за закона дырявых абстракций вот что получается: придумает кто-нибудь чудесный новый генератор кода, с которым у программиста работа наконец-то станет эффективной, а ему и говорят: «Сперва научись делать это руками, а потом уж пользуйся генератором, чтобы сэкономить время». Генераторы кода, абстрагирующие разработку кусков кода, так же дырявы, как и все прочие абстракции. А единственный компетентный способ залатать эти дыры — выучить, как работают абстракции, и какие подробности они скрывают. Итак, абстракции экономят наше рабочее время, но не экономят учебное время.

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

Ну, комментарии типа
// здесь мы получим данные из базы
И правда не слишком полезны.

А вот описание алгоритма аггрегации данных должно быть.

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

Я так понимаю, о технических комментариях АКА phpdoc (о которых говорит тов. куратор) речь сейчас не идет. Если идет, то автор приглашается объяснить, чем они его не устраивают.

Если же автор говорит о пояснениях к коду, то позиция совершенно правильная, такой подход называется самодокументируемый код, впервые упомянутый великим Фредериком Бруксом еще в 60-х годах прошлого века.

как минимум комменты помогают автоматическому дополнению кода и линтерам.
плюс, по ним можно автоматически строить документацию.

комменты ради комментов - никому не уперлись.