Прошу прощения, тему можно удалить, проблему решил: имногда надо отвлекаться, а то глаз замыливается
12.01.2012 03:16:36
|
|||
|
28.11.2011 12:14:57
При включенном кешировании компонента bitrix:menu отказывается выполняться код result_modifier.php.Вот содержимое:
Fatal error: Class 'CIBlockSection' not found in /bitrix/templates/main/components/bitrix/menu/catalog-menu/result_modifier.php on line 17 Строка 17 - это $dbSection = CIBlockSection::GetByID($matches[0]); Разве не должен result_modifier.php кешироваться вместе с шаблоном вывода компонента? |
|||
|
28.10.2011 17:36:52
Речь идет, в первую очередь о возможно уязвимости (переполнение дискового пространстра, к примеру).Я считаю, что в данной проблеме необходимо разобраться, и исправить.
Во-первых, весь этот кэш не попадает в таблицу b_cache_tags, соотвественно, возникает вопрос, каким образо само ядро за ним следит? Во-вторых, файлы в папке /bitrix/cache/search выглядят уж сильно подозрительно: его размер 140 Кб, а состоит он в основном из пустого сериализованного массива (b:1;s:3:"";b:1;s:3:""; - повторяется на протяжении почти всего файла). |
|
|
28.10.2011 17:20:17
К примеру, листинг файла из /bitrix/cache/2b/
Я бы сказал, что это что-то связанное с заказами и корзиной, но этот листинг взят с локальной копии сайта, где никто ничего не покупал и не просматривал. Ниже листинг файла из /bitrix/cache/search/48/
|
|||||
|
28.10.2011 16:40:55
Добрый день, после обновления сайта с версии 10 до версии 11 получил картину, никак не вписывающую в мое мировосприятие:в папке /bitrix/cache, помимо папки s1 (ID сайта) стали появляться папки с кэшами. После удаления, соответственно, они появляются снова.
На сайте не используется "ручное" кеширование, следовательно путь "/" для кэша нигде не установлен. Кроме того, появилась папка /bitrix/cache/search и файл /bitrix/cache/smtpd_stats.php. Хотелось бы узнать у гуру, какие компоненты/модули в обновлении создают неупорядоченный кэш? Выяснить через таблицу b_cache_tags не получилось - там этих данных просто нет. |
|
|
14.10.2011 15:21:29
Та же беда:
Функция расположена в init.php, в начале функции взываем к $APPLICATION (global $APPLICATION). Работаю с модулем инфоблоков через административный интерфейс. |
|||
|
12.07.2011 14:05:14
Еще замечено следующее: в админке при включенной статистике постоянно пишется "объем кэша 2мб", админка работает очень медлено, папка Stack_cache после очищения почти сразу становится объемом 2Мб.
Весь этот объем приходится на /bitrix/stack_cache/MYSQL/b_iblock - там лежит очень тяжелый один файл с кэшем. Как можно уменьшить его объем? Пока вопрос был решен определением константы BITRIX_SKIP_STACK_CACHE = true в init.php |
|
|
07.07.2011 18:15:04
Странно, но проблема решилась при отключении вывода кнопок редактирования для администратора:
|
|||
|
07.07.2011 13:10:53
Добрый день, подскажите пожалуйста, чем может быть обусловлено наличие избыточного объема кэшированых данных в компонентах.
К примеру, компонент вывода элемента инфоблока (catalog.element, не стандартный) при работе на сброшеный (пустой) кэш выводит:
А через какое-то время, при наличии уже кешированных данных начинает выводить:
После очистки кэша все работает опять хорошо. Пробовали различные вариации: с включенным "Управляемым кэшем" и без него. Все одно. |
|||||
|
18.01.2011 16:43:30
Добрый день. Сегодня столкнулся с такой ситуацией:
у элементов инфоблока имеется 16 свойств, 6 из них - неактивные. Надо получить значения этих шести (неактивных) свойств, выдать пользователю, и, после того как они будут отредактированы, записать их обрантно. Получить неактивные свойства - не проблема. Проблема встала в записи. Перепробовал методы SetPropertyValuesEx, SetPropertyValueCode - результат нулевой. Методы SetPropertyValues и CIBlockElement::Update применять не стал, т.к. нам требуется изменить не все свойства, а только 6. Тип всех изменяемых свойств - "число". При активировании этих свойств обновление работает любым методом. |
|
|