Приветствую, коллеги! Может кто-нибудь подсказать такой момент? Кэш битрикса в отдельной папке как-то удаляется сам по истечению времени кэширования или это происходит только при обращению к файлам кэша?
Привет, коллеги! Подскажите, кто знает. Исходно кеш компонента изменяется при изменении или добавлении элемента. Но из этого вытекает, что при изменении и добавления раздела кеш не изменяется (не помню, чтобы об этом где-то сообщалось).
Отсюда вопрос, как сделать, чтобы при изменении раздела сменялся кеш компонента? В документации есть что угодно и ClearResultCache и тегированый кеш, и как он устроен, и какие виды (с полной путаницей по ним, кстати) только не информация о том, как просто потереть кеш того компонента, который нужен при необходимых изменениях, например по событию. Или хотя бы как найти путь к нужному кешу, потому что не зная пути - найти его просто не реально.
Жуков Евгений, как всегда ничего конкретного. Отписались документацией, которую скорее всего сами до конца понять не в состоянии. А если учесть, что информации уже более 8 лет, то вообще дела плохи. Годы идут, а какое было к документации отношение - таким и осталось.
Удовиченко Юрий, у всех стандартных компонентов есть тег кеша вида iblock_id_4, где 4 - это ID инфоблока.
Такой штуки там нет $CACHE_MANAGER->RegisterTag("iblock_id_4"), потому что тег кеша незаметно вставляется с помощью медтодов Fetch, которые по любому есть.
При редактировании чего-либо в инфоблоке сбрасывается тег iblock_id_4, и кеш всех компонентов, которые его содержат становится устаревшим.
Если у вас задача, чтобы только при смене раздела менялся кеш, сделайте в компоненте $CACHE_MANAGER->RegisterTag("my_iblock_section_id_1234"), и сбрасывайте свой тег при редактировании разделов.
Регистрировать теги можно и в result_modifier.php, если шаблон кешируется.
Всем привет! Появился неожиданный вопрос после того как завалил одно из собеседований. Интересно мнение профессионалов...
Начал разбираться с паттерном MVC и как он на самом деле представлен в битриксе. Мнений в сети много. В документации сказано, что данный паттерн реализован просто наилучшим образом (см. цитату Степана Овчинникова) . Но в реальной жизни соображения не всегда столь же радужные.
А путаница на самом деле дикая, начиная с первой же картинки той же документации. Казалось бы, почему контроллер (который является компонентом битрикса) вообще никак не взаимодействует с моделью, и почему это представление напрямую воздействует на модель? В моей голове рисовалась совсем иная картина. О том, что все данные от пользователя проходят через контроллер, отправляются в модель, возвращаются изменёнными и отображаются обратно в представление (как собственно оно и реализовано в Битриксе). Но покопавшись ещё немного, оказалось, что такая модель называется вовсе не MVC, а MVP !
А вот по MVC каких только стрелочек от одного блока к другому всюду ни нарисовано, и везде разные! Единой картинки нет. И всё же, если обратиться к википедии (будь она неладна), то получаем вот что: - т.е. подразумевается, что после получения запроса от пользователя контроллер отправляет запрос в модель, данные изменяются, и МОДЕЛЬ НАПРЯМУЮ МЕНЯЕТ ПРЕДСТАВЛЕНИЕ! Позвольте, но это же совсем не то ,что мы имеем в битриксе! Только при Ajax бескомпозитной работе модель напрямую, без вызова компонента и без всякой инкапсуляции выдаст данные для последующего изменения представления. Но ведь это нестандарт, согласно теории битрикса!
Отсюда и вопрос. Уважаемые разработчики! Либо я (не побоюсь этого слова) балбес и ничего не понимаю в MVC, либо в битриксе реализован в основном паттерн MVP, а не MVC. И уж точно картинка из документации совершенно под него не подходит. Какие будут мнения на этот счет? (P.S. Ненормативная лексика будет нещадно баниться).
Привет друзья! Есть задача отправить 5К пользователям сообщение о том, что их аккаунты перенесли на новый сайт. Кто-нибудь знает, если это делать ч/з Event::send, то битрикс сама разграничит отправку по времени?
Т.е. можно не заморачиваться и отправлять на отправку сразу все записи, и они через агента по-немногу разошлются сами или нужно заморачиваться и делать это медленно и постепенно?
При вызове события OnBeforeUserUpdate получаем некоторые пользовательские поля (тип множественный файл). В них массив собственно информации о файлах и их изменении, примерно такого вида: [name =>, del =>, old_id =>, error =>] - так вот в error прописывается int(4).
Кто-нибудь сталкивался что это за ошибка, и где есть их список? В документации ничего об этом нет.
P.S. Сохранение пользователя происходит отлично. Можно бы не обращать внимания, но всё же...
Всем привет! Подскажите, кто-нибудь знает, способ массового удаления или деактивации элементов (по массиву ID элементов) штатными способами так и не реализован?
При использовании D7 \Bitrix\Iblock\ElementTable::update результат передаёт сообщение "Для изменения элементов инфоблоков используйте вызов CIBlockElement::Update()". А в этом методе, как известно, можно передать только один элемент.
Не хотелось бы изменять напрямую через запрос к БД. Кто его знает, что там может быть понавешено при деактивации. А при удалении тем более.
Друзья, подскажите, какой курс необходимо пройти, чтобы поэтапно понять, чем отличается Bitrix24 (коробка) от БУС ? В сети лишь сумбур и множество разрозненных постов. Даже информация от Ивана Малышина (Руководитель образовательного направления «1С-Битрикс») не особо помогла.
Можете поделиться опытом, как вы сами обучались и разбирались в работе этого коробочного зверя? С чего начать, есть ли какая-то более менее полноценная информация, или это только платные курсы, или собственноручное копание в коде, и никак иначе?
Хорошо, действительно спасибо за ссылки. Я понял, что проблема на самом деле в наименовании документации. Нигде в официальных ссылках, представленных выше не написано, что это начальная документация для разработчиков по Б24. Что угодно: Rest, маркетплейс, приложения Б24 - но только нигде не сказано, что это основы. На этом дискуссию думаю имеет смысл завершить. Спасибо, что откликнулись. Просто примите это как обратную связь, что начинающим по Б24 (хоть и получившим сертификат разработчика по БУС) - далеко не очевидно, что все эти вышеперечисленные документации являются основой Б24.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
