Andrews32

В общем попался на такую же проблему, долго не мог понять, почему так происходит. Надеюсь кому-нибудь поможет:

Дело в пути, на котором лежит папка. У меня возникала эта ошибка на win10 если в пути к работей папке были русские символу и знак "[ или ]"

.pipe(htmlmin({
collapseWhitespace: true,
removeComments: true
}))

https://github.com/kangax/html-minifier#options-qu...

как вариант
$ npm install --save-dev gulp-remove-html-comments

var gulp = require('gulp');
var removeHtmlComments = require('gulp-remove-html-comments');
 
gulp.task('html', function () {
  return gulp.src('src/*.html')
    .pipe(removeHtmlComments())
    .pipe(gulp.dest('dist'));
});

https://www.npmjs.com/package/gulp-remove-html-comments

там подробней

offsetParent – «родитель по дереву рендеринга» – ближайшая ячейка таблицы, body для статического позиционирования или ближайший позиционированный элемент для других типов позиционирования.
offsetLeft/offsetTop – позиция в пикселях левого верхнего угла блока, относительно его offsetParent.
offsetWidth/offsetHeight – «внешняя» ширина/высота блока, включая рамки.
clientLeft/clientTop – отступ области содержимого от левого-верхнего угла элемента. Если операционная система располагает вертикальную прокрутку справа, то равны ширинам левой/верхней рамки, если же слева (ОС на иврите, арабском), то clientLeft включает в себя прокрутку.
clientWidth/clientHeight – ширина/высота содержимого вместе с полями padding, но без полосы прокрутки.
scrollWidth/scrollHeight – ширина/высота содержимого, включая прокручиваемую область. Включает в себя padding и не включает полосы прокрутки.
scrollLeft/scrollTop – ширина/высота прокрученной части документа, считается от верхнего левого угла.

Остановите клиент. Убедитесь что не запущен.
Смените порт в конфиге. Запускайте.

Хоть и поздно, но всё же, вдруг кому пригодится. Можно через хук:

add_filter( 'option_default_product_cat', function( $value, $option ) {
	return false;
}, 9999, 2 );

Вообще то значения массива arFilter поддерживают массивы.

$arFilter = Array("IBLOCK_ID"=>1, "ID"=>array(1,2,3));
$res = CIBlockElement::GetList(Array(), $arFilter, false, false, array());
while($ob = $res->Fetch())
{
 
}

Во многих готовых решениях это есть.
Самое простое - хранить в сессии ID избранных товаров. Это если не надо долго их там держать. Если долго, то 1 своя таблица. Всего 2 поля. USER_ID и PRODUCT_ID, их оба объявить как primary (составной ключ). Компонент для вывода будет совсем простой.

Эээ... а что вы сделать то хотите ?

Я вот о чем говорю: при использовании ООП в bitrix вы сталкиваетесь сразу с 2 большими стенами - применение ооп и битрикс. Прежде чем разбирать конкретный код хотелось бы немножко просветить вас в самой архитектуре битрикса.
В терминологии Битрикса он использует концепцию MVC, но в рамках битрикса, а это означает что на любой странице где вы общаетесь с ним вы должны подключить пролог (хотя бы prolog_before) и эпилог (хотя бы epilog_after, ну в идеале). Именно "компонент" и является тем самым MVC (Вообще это скорее VC + row access, так как модели по сути нет). Есть класс CBitrixComponent (контроллер) и класс CBitrixComponentTemplate (который совместно с файлами шаблона и образует view).

Вызов компонента происходит из глобальной переменной $APPLICATION путем метода IncludeComponent. До версии 14 (если мне не изменяет память) вообще не было такого понятия как class.php, где можно было отнаследоваться от CBitrixComponent и перекрыть какие-нибудь функции (шаблонизатор к примеру сменить), а после нового ядра d7 появилась возможность отнаследоваться от CBitrixComponent и в файле class.php разместить свой код (таким образом мы сохраняем и class.php с новыми функциями и component.php с логикой), а перекрывая метод executeComponent вы можете избавиться и от component.php.

С точки зрения архитектуры (рекомендую изучить документацию, она очень обширна и познавательна) все компоненты должны лежать в так называемом пространстве имен, чем обычно служит ник-нейм или название компании (Естественно начинается не с цифры и содержит только латинские буквы), которые в свою очередь могут располагаться в /bitix/components/#пространство_имен#/#название_компонента#/

Теперь построчно разберем Ваш вопрос:

Вы положили свой класс сюда: /bitrix/templates/app/Pi/Test.php, что является неверным с точки зрения архитектуры, так как поместили класс отвечающий за контроллер в папку с шаблоном. Если вы не пишете свой модуль вы можете подключить его например в /local/php_interface/classes/ (пример надуманный, можете просто в /local/php_interface положить или сразу в init.php), однако для этого вы должны будете написать autoloader, так как у битрикса он работает только для модулей. Предположим вы в init.php напишете грубый require_once с файлом.

Затем вы делаете следующее:

Что является неверным, так как по сути вы обьявляете неймспейс для файла и это с точки зрения php выглядит вот так в конечном итоге:

class app\Pi\test extends app\Pi\CBitrixComponent
{
// ...
}

А класса app\Pi\CBitrixComponent не существует. Так что вам нужно поправить пример хотя бы так:

class test extends \CBitrixComponent

Настоятельно рекомендую прочитать документацию или хотя бы посмотреть видео с академии битрикс. Сама система не подарок, а другой программист который увидит ваш код будет говорить что это битрикс виноват.

Многие запросы на битрикс немного ускоряются, если уточнить запрос, например вместо 'IBLOCK_ID'=>10 указывать '=IBLOCK_ID'=>10

Найти место, где генерятся эти запросы не сложно - достаточно запустить Монитор производительности с записью sql-запросов.

Так найдется место где неоптимизированный запрос. На вкладке с запросами можно будет запустить анализ индексов.

Уменьшите количество элементов на страницу, включите кэширование, удалите неиспользуемые свойства, выводите только нужные, проведите оптимизацию на странице производительности, пересоздайте фасетный поиск. Проверьте компоненты на сторонний код. Смотрите сервер - сколько памяти и как она расходуется, используйте php7
Короче тут можно трехтомник писать этих советов)