Кеш на компоненте занимает мегабайты, в случае если у секций есть длинные описания, либо много свойств.
Нужно это поправить.
1/ Массив $arResult['SECTION'] и подмассив $arResult["SECTION"]["PATH"]: зачем сохранять в кеше все поля секций, даже SEARCHABLE_CONTENT? для сео они все не нужны.
2/ Зачем сохранять все свойства элемента в кеш и даже пустые? Массив $arResult['PROPERTIES'] - зачем все сохраняются? для сео и прочего лишь некоторые ведь нужны... Надо лишние убирать.
После удаления лишнего из кеша, объем этого самого кеша уменьшается с 3мб до 90кб. Считаю, что нужно внедрить это в компонент bitrix:catalog.element.
Пример решения через result_modifier.php компонента bitrix:catalog.element:
// clear unused cache fields
foreach ($arResult['PROPERTIES'] as $k => $prop) {
if (trim($prop['VALUE']) == '') {
unset($arResult['PROPERTIES'][$k]);
}
}
$arDeleteSectionKeys = array('SEARCHABLE_CONTENT', '~SEARCHABLE_CONTENT');
foreach ($arResult['SECTION'] as $k => $s) {
if ($k == 'PATH') {
foreach ($s as $ks => $ss) {
foreach ($ss as $kss => $ss2) {
if (in_array($kss, $arDeleteSectionKeys)) {
unset($arResult['SECTION'][$k][$ks][$kss]);
}
}
}
} else if (in_array($k, $arDeleteSectionKeys)) {
unset($arResult['SECTION'][$k]);
}
}
iblock 16.6.1. изменения затронут так же news.detail. п.1 Оставили только часть полей п.2. Ключ PROPERTIES больше не сохраняется вообще - в нем больше нет необходимости
В параметр $arNavStartParams добавить еще обработку nTopCount, чтобы не использовать для этих целей nPageSize, который вызывает обработку наличия постраничной навигации на странице, повышающий PAGE_NUMBER на один.
Сейчас при использовании стандартного и идущего из коробки с версии PHP 5.5 акселератора Zend OPcache, монитор производительности ругается на то, что не установлен ни какой акселератор:
Модуль торгового каталога и интернет магазина зависит от модуля валют (без него не работает). Итого, кто мне объяснит наличие такого же класса и метода CCurrencyRates::ConvertCurrency() во всех этих трех модулях?
вот где есть класс CCurrencyRates и метод у него ConvertCurrency():
Ни в sale, ни в catalog нет такого класса. Он есть только в модуле currency. Обратитесь в техподдержку, раз на Вашей установке наблюдается такая картина.
Сделать возможность писать свои автопогрузчики классов, либо стандартизировать эту операцию.
Выходит, что сейчас максимум что можно - это сделать автозагрузку в рамках своего модуля, как описано в блоге. А если мне не нужен модуль? А если мне нужна некая своя "библиотека классов", которые я, допустим, в компонентах дергаю? Мне все время include необходимого класса писать в init.php? Хочется по-людски управлять этим процессом...
Я делал следующий хак: подрубал файл в dbconn.php и переопределял функцию __autoload(). (До того, как битрикс эту функцию "захавает" под себя). Это все под PHP 5.3 было. Хака, чтобы использовать spl_autoload_register() я не нашел.
Что я предлагаю, и что было бы удобно: некий способ, который позволит повесить событие и указать свой обработчик автозагрузки. При этом система битрикс будет искать неопределенный класс используя этот произвольный обработчик.
Сейчас с этим полный "баян", а хочется что-то хорошее...
п.1 Оставили только часть полей
п.2. Ключ PROPERTIES больше не сохраняется вообще - в нем больше нет необходимости