Как переиспользовать компоненты битрикс

Выводим компонент в шаблоне другого компонента | Статьи CMS «1С Битрикс»

Вывести компонент в шаблоне другого компонента, при условии включенного кэширования Битрикс.

Решение

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

Для решения этой проблемы можно воспользоватья файлом component_epilog.php

Добавим метку в шаблон основного компонента (template.php)

if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true)die(); $this->setFrameMode(true); // начинаем буферизацию вывода ob_start(); // тут разметка и код основного компонента, а в нужном месте вставляем метку: #INNER_BLOCK_1#  // передаем данные буфера вывода в файл component_epilog.php $this->__component->SetResultCacheKeys(array("CACHED_TPL")); $this->__component->arResult["CACHED_TPL"] = @ob_get_contents(); ob_get_clean(); ?> 

 require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php"); /** * @var CMain $APPLICATION * @var array $arResult */ // callback function $replacer = function ($matches) use ($APPLICATION)  ob_start(); // тут вставляем разменту, вызовы компонентов, в общем все что нужно вывести // в метке #INNER_BLOCK_123# мы можем передать в качестве числа например код инфоблока // и использовать его так : $id = $matches[1]; // например в вызове компонента списка новостей: $APPLICATION->IncludeComponent( "bitrix:news.list", "article-list", Array( 'IBLOCK_ID' => $id, // тут миллион параметров компонента ) ); return ob_get_clean(); >; // находим метку и заменяем ее на результат работы нашей функции echo preg_replace_callback( "/#INNER_BLOCK_([\\d]+)#/is" . BX_UTF_PCRE_MODIFIER, $replacer, $arResult["CACHED_TPL"] ); 

Решение 2

 $this->setViewTarget('view_marker'); ?> тут код шаблона компонента  $this->endViewTarget(); ?> 

 $APPLICATION->getViewContent('view_marker') ?> 

4 способа расширить стандартные компоненты 1С-Битрикс

Часто в своей работе сталкиваюсь с сайтами, написанными целиком на самодельных компонентах, без использования стандартных. Поддержка таких сайтов со временем превращается в сущий ад: каждое изменение в логике/структуре/выводе информации требует доработку всего компонента. А это не правильно.

Еще пару лет назад я и сам бы предпочел написать еще один компонент по выборке/добавлению/изменению элементов инфоблока. Да, в каких-то ситуациях это имеет смысл: нужен компонент для своего модуля, скорость работы стандартного компонента не устраивает (и ни что не получается с этим сделать), слишком много ненужного функционала (а отключить все, кроме нужного нельзя). Но как правило это не будет лучшим решением.

Механизм компонентов Bitrix имеет ряд инструментов, позволяющих расширять стандартный функционал, изменяя их под свои нужды.

Кроме этого, существует пара приемов, облегчающих работу с шаблонами: они позволяют вынести css и js код в файлы шаблона и вызывать только на страницах, где они действительно нужны.

1. Добавляем пользовательские настройки

Файл .parameters.php в шаблоне компонента

При создании шаблона компонента, часто возникает необходимость ввести какие-то дополнительные настройки. Для примера представим, что необходимо сделать слайдер последних новостей. Мы, как опытные разработчики, решили использовать компонент списка новостей (bitrix:news.list) и подключить в шаблоне JS библиотеку. Но вот незадача, для нашего любимого скрипта необходимо проставить скорость смены слайда и эффект перехода.

Боже, сколько раз я сталкивался с тем, что такие параметры просто хардкодят в шаблонах. Ну да, правильно, так же быстрее, да и работает отлично. Только вот заказчикам придется бегать к разработчикам каждый раз, когда нужно сменить эффект или чуть-чуть уменьшить скорость (читай каждый день).

Слава богу, этого можно легко избежать. Скопируем для начала шаблон компонента.

Если сейчас заглянуть в структуру, можно заметить, что у нас уже есть файлы .parameters.php и style.css. Они скопировались из дефолтного шаблона, для чистоты эксперимента давайте представим, что их не было (тем более, в большинстве случаев, стандартные шаблоны содержат только template.php и папку с lang файлами).

Дальше создадим файл .parameters.php, его структура схожа с параметры компонента. Подробнее про настройки параметров компонента я писал здесь.

А теперь опишем необходимые свойства: SLIDER_EFFECT со списком возможных переходов и SLIDER_TIME, куда мы будем вводить время смены слайдов

 array( 'NAME' => 'Эффект смены слайдов', 'TYPE' => 'LIST', 'SORT' => '10', 'VALUES' => array( 'sliding' => 'Скольжение', 'fading' => 'Затухание', ), 'MULTIPLE' => 'N', ), 'SLIDER_TIME' => array( 'NAME' => 'Скорочть смены слайдов (мс)', 'TYPE' => 'STRING', 'SORT' => '20', 'DEFAULT' => '5000', ), ); ?>

Теперь наши свойства можно найти в настройках компонента в разделе «Дополнительные настройки» и использовать в шаблоне, как и другие параметры $arParams.

2. Расширяем функциональность

Файлы result_modifier.php и component_epilog.php

Давайте представим другую ситуацию. В инфоблоке новостей есть свойство «Привязка к пользователю», нам необходимо вывести всё те же последние записи, но кроме стандартных полей надо показать имя пользователя, создавшего новость. Стандартные компоненты такое делать не умеют.

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

Как раз для таких случаев используются файлы result_modifier.php и component_epilog.php.

Чтоб понять в чем между ними разница, давайте для начала взглянем на схему работы компонентов в Bitrix.

Как видно из схемы, result_modifier.php подключается сразу после component.php. В нем можно, например, получить дополнительные данные и, записав их в $arResult, передать дальше в шаблон компонента. Подробнее про файл result_modifier в официальной документации .

Файл component_epilog.php нужен для изменения закешированных данных. Код, помещенный в файл, будет выполняться в любом случае, независимо от того, отдается информация из кэша или получается в ходе работы component.php. Официальная документация .

Давайте создадим файл result_modifier.php и получим необходимые данные.

 // Получение списка пользователей по их ID $dbUsers = CUser::GetList( ($by = 'id'), ($order = 'asc'), array( 'SELECT' => array( 'ID' => implode(' ! ', $usersID), ) ) ); while ($arUsers = $dbUsers->Fetch()) < // Передаем новые данные в шаблон, записав их в $arResult $arResult['USERS'][$arUsers['ID']] = $arUsers['NAME']; >

Готово. Теперь в шаблоне мы можем по ключу вывести имена пользователей.

3. Добавляем много JS кода

Файл script.js

1. Вызывать скрипт в шаблоне сайта. Но тогда он будет подключаться на каждой странице, вне зависимости есть там компонент или нет
2. Вызывать скрипт вне компонента на странице. Чуть лучше, но есть большая вероятность, что контент редактор случайно сотрет ваш код, и слайдер перестанет работать.
3. Написать код в шаблоне компонента. Не самое изящное решение, js код большой, он перемешается с кодом шаблона, работать будет неудобно.
4. Создать файл script.js, который подключится к шаблону автоматически. Идеально.

4. Добавляем стили компонента

Файл style.css

Такая же ситуация и с CSS. Если вы не хотите, чтоб template_styles.css шаблона сайта неимоверно разрастался и тянул за собой всё оформление (используется оно на странице или нет) можно вынести специфичные стили в style.css шаблона компонента.

После создания, файл подключится автоматически везде, где используется компонент с данным шаблоном.

Как в Bitrix вывести компонент в переменную?

Есть некое приложение, которое через ajax общается с бекэндом (приложение отправляет запрос, в ответ получает json и с ним работает).
Мне, предположим, надо получить одним запросом список товаров той или иной категории и хлебные крошки (может быть еще какие-то данные).
И в битрикс есть компоненты, которые уже получают нужные мне данные (bitrix:breadcrumb, bitrix:catalog.section — остается только добавить новый шаблон, который вместо генерации html упакует нужные данные в json),
но если я в коде обработчика буду вызывать эти компоненты, то результат работа компонента я получу в виде вывода в браузер (echo), а не в переменную, что по сути не дает мне возможности работать с теми данными, которые компонент выдал — они уже в потоке вывода (что кстати помимо прочего ломает json ответа).
Думал сделать через буферизацию, но получается ерунда какая-то
вот некий метод, который получать должен результат работы компонента

private function component($name, $params) < global $APPLICATION; ob_start(); $APPLICATION->IncludeComponent( "bitrix:breadcrumb", "json", Array( "PATH" => "/catalog/zhenskaya-odezhda", "SITE_ID" => "s1", "START_FROM" => "0", ), false, ["HIDE_ICONS"=>"Y"] ); $d = ob_get_clean(); var_dump([ 'd' => $d ]); >

но в результате вывода

[]array(1) < ["d"]=>string(0) "" > >

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

• Вопрос задан более трёх лет назад
• 1095 просмотров

Азы разработки на Битрикс

Дабы не было не понимания, скажу сразу, данный пост я писал для людей, которые только начинают знакомиться с CMS 1С-Битрикс. Можно сказать это краткий ликбез по принципу работы данной системы. Я опишу из каких компонентов она состоит, что за что отвечает и как формируется web страница. Рекомендую прочесть данный пост перед изучением официальной документации

• курс разработчика http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&INDEX=Y
• документация по API http://dev.1c-bitrix.ru/user_help/index.php

или как вариант после, для повторения основных моментов.

Начну с небольшого пролога, система 1С-Битрикс разработана на основе Bitrix Framework. Которая в свою очередь, вроде как основывается на Zend Framework, в официальной документации об этом сказано в скользь. Данный фреймворк построен по принципу Model-View-Controller, написан на PHP и использует в качестве СУБД следующие продукты: MySQL, Oracle, MS SQL.

CMS 1С-Битрикс платная, но есть бесплатная 30-дневная пробная версия, которую можно скачать на официальном сайте (в гугле не сложно найти).

Логически 1С-Битрикс можно разбить не следующие элементы:
Сравнивая 1С-Битрикс с шаблоном проектирования Model-View-Controller, можно сказать что:

• Модуль в 1С-Битрикс это модель в MVC.
• Компонент в 1С-Битрикс это контроллер и представление в MVC (компонент с помощью API одного или нескольких модулей манипулирует данными, а шаблон компонента (представление) выводит данные на страницу).
• Шаблон в 1С-Битрикс это чистое представление в понятии MVC (от него зависит не содержимое сайта а его оформление).

P.S. Это деление условно, т.к. я считаю, что фреймворк Bitrix придерживается технологии MVC не достаточно строго.

Начнем с модулей…

Модули располагаются в /bitrix/modules/, задача каждого из них – предоставить API для выполнения той или иной функцию для CMS в целом, например: дать возможность хранить и выводить информациювроде статей, новостей, фотогалерей (модуль «информационные блоки»); организовать интернет-магазин(модуль «Интернет-магазин»); гибко управлять ценами на товар и связывать интернет-магазин с 1С:Предприятие и другими сервисами вроде Яндекс.Маркет (модуль «Торговый каталог»); датьвозможность организовать блог (модуль «Блоги»), форум (модуль «Форумы») и т.п. Предоставляемые модулями функции могут использовать как другие модули так и компоненты.

Помимо модулей, задача которых в расширение возможностей, существуют модули обеспечивающие работу самой CMS, например : модуль с именем «Главный модуль» – отвечает за общее функционирование системы и взаимодействие всех модулей; модуль «Управление структурой сайта» – предоставляет панель администратора и т.д..

Вообщем, если обобщить выше сказанное, возможности CMS 1С-Битрикс зависят от состава модулей. Состав может быть минимальным, имея только необходимые модули и немного функциональных, а может быть распухшим с набитыми кучей модулей на все случаи жизни. Поэтому в зависимости от поставленных задач CMS 1С-Битрикс продается в разных исполнениях – называемыми редакциями, перечислю их:

• Первый сайт (5 модулей)
• Старт (11 модулей)
• Стандарт (19 модулей)
• Малый бизнес (25 модуля)
• Эксперт (33 модуля)
• Бизнес (40 модулей)
• Веб-кластер (40 модулей)
• Бизнес веб-кластер (43 модулей)

Касаться технических сторон создания своих модулей я не буду, думаю web-разработчикам, которые только знакомятся с 1С-Битрикс знать о таких подробностях пока излишне. Вы всегда можете найти всю необходимую информацию в официальной документации (ссылки указанны в начале поста).

О компонентах…

Про компоненты я расскажу более подробно, править их вы будете намного чаще, чем модули. Хочу внести ясность и однозначность в понимание понятие «компонента» в данной системе. Если вы работали на других CMS, то может возникнуть путаница, традиционно модулями в CMS называют некиефункциональные расширения, которые можно устанавливать/удалить, скачивать и разрабатывать самому. Например, это может быть модуль вывода формы на e-mail подписку или модуль выводящий список популярных постов. В CMS 1С-Битрикс эту роль играют – компоненты. Список доступных компонентов вы можете увидеть в данной директории www\bitrix\components\. Где директория bitrix это пространство имен для данных компонентов, нам как бы говорят что они «битриксовые», т.е. идут с системой из коробки.

Реализация логики и способа отображения компонента содержится в двух файлах:

• В контроллере

www\bitrix\components\bitrix\имя_компонента\component.php

• И в представление (так называемый шаблон компонента) —

www\bitrix\components\bitrix\имя_компонента\templates\имя_ша ­блона_компонента\template.php .

Суть работы компонента хорошо описана в официальной документации, повторю их слова еще раз «компонент (т.е. его контроллер замечание от меня), с помощью API одного или нескольких модулей, манипулирует данными, шаблон компонента выводит данные на страницу».

Компонент в своем составе может иметь несколько шаблонов, один из которых будет активным(указывается при вызове компонента).

Помимо контроллера и представления, компонент имеет файлы, выполняющие более второстепенные задачи: файл – содержимого справки, логотип компонента для админпанели, файл-описание компонента для админпанели и т.п.

Типичная структура компонента выглядит так:

• help (директория, файлы справки компонента, т.е. всплывающие подсказки при настройке компонента)
• images (директория, изображения которые использует компонент)
• lang (директория, содержит подпапки с языковыми файлами)
• templates (директория с шаблонами, т.е. с представлениями)
• .description.php (файл с описанием компонента)
• .parameters.php (файл содержит описание входных параметров компонента, файл нужен только для конфигурирование компонента через окошко)
• component.php (файл (контроллер), основная логика компонента)

Зайдя в директорию любого компонента (www\bitrix\components\пространство_имен\имя_компонента) вы всегда увидите схожую стркутуру, как продемонстрировано выше. Стоит добавить, что компонент все для своей работы хранит в своей папки, поэтому переносить компонент с одного web сайта на другой web сайт – значит просто скопировать папку.

Технически работу компонента можно представить следующим образом: в шаблоне сайта (footer.php или header.php, о них я расскажу позже) вызывается компонент с заданными шаблоном и параметрами:

Далее CMS формирует массив с параметрами $arParams, который обрабатывает контроллер «component.php». Контроллер (component.php) согласно своей логике работы и полученного массива параметров формирует результат своей работы, т.е. массив $arResult, который далее использует шаблон компонента (templates\имя_шаблона_компонента\template.php). Представление (или шаблон компонента) отображает результат работы в виде html кода, в задуманном оформление, в том месте где вы вызвали указанный выше код.

Параметры массива arParams=array() можно задать через запяту напрямую в коде (“ключ” => “значение”) или через окошко «параметры компонента». Хочу добавить, что если изменять параметры через окошко«параметры компонента», то они все равно сохраняются в коде, как содержимое массива arParams. Что бы вызвать это окно, первым делом нужно авторизоваться в системе как администратор, далее зайти на сам сайт, выбрать компоненты -> режим правки, далее кликнуть по нужному компоненту два раза.

Как пример, на пальцах. В желтом овале компонент «bitrix:search.form» (перед двоеточием пространство имен в котором данный компонент, после название компонента), по которому я тыкнул два раза. Далее откроется окошко «параметры компонента». Если мы изменим значение параметра (тот что в красном овале) и нажмем сохранить. То в соответствующем файле представления шаблона (footer.php или header.php, о них я расскажу позже), в коде вызова компонента (обозначил зеленой рамкой) измениться значение параметра (в красном кружке). И наоборот, изменения в коде, будут заметны через окошко.

Замечу еще, что шаблоны компонентов могут быть системными и пользовательскими. Системные это те, что уже идут в стандартной поставки и распологаются в дриектории «www\bitrix\components\bitrix\имя_компонента\templates\». Если нам нужен свой шаблон для компонента, то мы должны создать пользовательским шаблон, и поместить его в папку со своим шаблоном сайта, т.е. по следующему адресу «www\bitrix\templates\имя_шаблона_сайта\components\bitrix\имя ­_компонента\имя_шаблона_компонента». Дальше, остается подключить наш пользовательский шаблон к компоненту, это можно сделать в визуальном редакторе шаблона (при двойном шелчке по нему) или подправить код его вызова (второй параметр $APPLICATION->IncludeComponent(…)).

Если при вызове или настройке компонента шаблон не указывается, то используется системный шаблон «.default».

В том случае если изменением шаблона компонента вам будем мало, допустим вы хотите выводить какую-то еще информацию в шаблоне, помимо той что может обеспечить логика компонента (component.php). То вы можете добавить в директорию пользовательского шаблона компонента файл – файлresult_modifier.php (в нем мы работаем с $arResult перед кешированием) и файл component_epilog.php (в нем работаем с $arResult после кеширования), таким образом вы дополняете нужную вам функциональность в компонент не изменяя его контроллер (т.е. component.php). Это хорошее правило, ведь все изменения в работе чего либо в CMS должны приходить и уходить вместе с шаблоном сайта, плюс к этому, системный компонент можно спокойно обновлять, до новых версий.

Есть правда и другой способ добавления функциональности, копируем тот компонент, который хотим изменить из www\bitrix\components\bitrix в свое пространство именwww\bitrix\components\мое_прост_имен, далее делаем с ним что хотим, добавляем нужный функционал и вызываем его вместо прежнего компонента в шаблоне сайта (footer.php или header.php). Но в этом случае обновляться будет только системный компонент. Этот способ стоит использовать если предыдущий метод (использовать файлы result_modifier.php и component_epilog.php в шаблоне компонента) не помогает достичь нужную вам функциональность.

P.S. В документации написано, что файл result_modifier.php подключается и исполняется, только тогда когда шаблон не кешируется, но у меня, на реальной практики он почему-то исполняется в любом случае.

И наконец шаблоны …

Тут все просто, шаблон в CMS 1C-Битрикс складывается из двух частей, верхней и нижней, все что между ними это информационное наполнение сайта, т.е. контент. Храняться шаблоны в директорииwww\bitrix\templates, каждая папка это отдельный шаблон. Среди папок вы всегда найдете «.default», это специальный «шаблон», он содержит шаблоны компонентов и файлы, общие для остальных шаблонов сайта. Трогать при интеграции макета мы его вряд ли будем.

Зайдя в директорию любого шаблона вы увидите следующую структуру:

• components (директория, содержит поддиректории с шаблонами компонент)
• images (директория, картинки данного шаблона)
• include_areas (директория, содержит файлы, которые включаются в шаблоне сайта)
• lang (директория, содержит языковые файлы)
• page_templates (директория, содержит файлы-шаблоны, они выводятся с помощью компонента «подключаемые области» (bitrix:main.include), при выводе в браузер данных шаблонов их содержимое наполняется в каждом отдельном разделе или подразделе с помощью файла index_inc.php)
• snippets (директория, содержит сниппеты – маленькие фрагменты html-кода для ускорения работы контент-менеджера по созданию часто встречающихся блоков кода)
• themes (директория, содержит подпаки с темами оформление данного шаблона, под темой понимается своя директория: с шаблонами компонент – components, директория – images с изображениями, файл с названием темы – description.php, изображение-превьюшки данной темы и файл стилей шаблона template_styles.css)
• header.php (файл, отвечающий за вывод верхней части шаблона, т.е. до контента)
• footer.php (файл, отвечающий за вывод нижний части шаблона, т.е. после контента)
• description.php (файл, содержит название и описание шаблона, которое выводиться в админпанели)
• .styles.php (файл, описания стилей для визуального редактора страниц)
• template_styles.css (файл, стили шаблона)
• styles.css (файл, стиль для контента и подключаемы областей, вообщем стиль контента сайта)

Обязательные файлы обеспечивающие минимум шаблона это:

Файл header.php – содержит html код с php вставками , в которых вызываются компоненты и подключаются файлы, в footer.php все аналогично. В данных файлах задается верхняя и нижняя часть шаблона.

Стили задаются в template_styles.css и styles.css.
Файл description.php необходим для описания шаблона для админпанели.

После всего сказанного у вас может возникнуть вопрос, если в header храниться верхняя часть шаблона а в footer нижняя а между ними контент, то к чему относить левую и правую боковую панелью(sidebar) ? Разработчики предлагают как вариант такое решение

Оранжевым цветом обозначено то что относиться к header.php, зеленым к footer.php, а голубым к контенту. Вы можете выбрать какой-то свой вариант. Могут быть ситуации, когда одна из боковых панелей зависит от каждой страницы сайта, тогда её логично вынести из дизайна шаблона и считать её контентом.

О разделах, подразделах и наполнение информации…

Итак, мы рассматриваем CMS 1С-Битрикс как взаимодействие модулей, компонентов и шаблона. И с ними мы вроде как разобрались, осталось понять как сайт в системе 1С-Битрикс наполнить информацией. А если быть точнее, то, как наполнить структурированной информацией, т.е. как создать разделы, если нужно подразделы разделов и страницы разделов.

Вообщем, раздел в Битрикс это просто директория, которая располагается в /www. Называть ее можно по любому, т.к. имя раздела в данной CMS не зависит от имени папки. В директории-раздел должны быть как минимум следующие файлы:

• index.php – центральная страница раздела, это php скрипт, отвечающий за наполнение контентом. В данном файле могут вызываеться компоненты, подключаться файлы, а также можно просто хранить статичный текст.
• .section.php – файл содержит описание – имя данного раздела

Помимо этих двух основных, могут быть еще файл:

.положение.menu.php – Файл php, отвечает за то, что показывать компоненту «меню» («menu»), когда мы зайдем в данный раздел сайта. Технически – это файл с массивом $aMenuLinks, в котором каждый элемент содержит название и ссылку. Данный файл считывает компонент «menu» и выводит соответствующие пункты меню. Вместо «положение» вы должны указать какой компонент «menu» (их может быть несколько) будет читать этот файл, это может быть «top», «right», «left» и т.д. Как задается тип компонента? Смотрим код вызова компонента «menu» (в header.php или foter.php) и обращаем внимание на параметр ROOT_MENU_TYPE, его значение и укажет его тип или что он будет читать: .top.menu.php или.left.menu.php и т.д.

Если шаблон компонента «menu» позволяет показывать подкаталоги (выдвижное меню), то мы должны указать какой файл читать для подкаталогов в параметре CHILD_MENU_TYPE.

Если файла «.положение.menu.php» в директории раздела не будет, то движок Битрикс будет искать его вкаталоге сверху, пока не найдет. Меню же нужно знать что выводить.

P.S. Помимо index.php в разделе могут быть другие страницы.

В любом разделе (или директории) могут быть подразделы (директории в данной директории), содержимое их аналогичное. Также хочу сказать, что директория www также имеет свой набор index.php,.section.php и .положение.menu.php, ее можно рассматривать как главный раздел сайта.

Наполнять сайт структурированной информацией (создавать разделы, подразделы, их страницы с информацией) можно как через панель администратора (красный овал)

так и вручную, т.е. сами создаем папки, необходимые файлы в них, редактируем файл “.положение.menu.php” в www (иначе нашего нового раздела не будет в меню).

На этом, данный пост я закончу. Для разработчика, который только знакомиться с CMS 1С-Битрикс данной информации будет достаточно что-бы примерно понять, что эта за система, удобна она или нет, найти сходства с другими CMS или наоборот увидеть явные различия. Это даст первое приближение, более глубокое погружение вы получите уже изучая документацию и работая с данной CMS.

Читать:

Как очистить память в вотсаппе а айфоне