14 заметок с тегом

1С-Битрикс

Позднее Ctrl + ↑

Бета-версия ББК

Большая часть алгоритмов компонентов повторяется. Дублирование кода усложняет поддержку и увеличивает время разработки. Два года назад вендор сделал шаг на встречу — внедрил поддержку ООП в компонентах. Но до сих пор не существует штатного компонента, от которого имело бы смысл наследоваться (компоненты меню и фильтра в расчёт не берём).

Необходимый минимум

Какие типовые задачи обычно выполняет некий абстрактный компонент?

  1. Подключение модулей.
  2. Проверка входящих параметров.
  3. Кеширование.
  4. Генерация строки постраничной навигации.
  5. Установка заголовков страницы.
  6. [Комплексный комп.] Определение запрашиваемой страницы.

Эталон

Продолжим список возможностей абстрактного эталонного компонента:

  1. Оперативное уведомление администратора о  «схваченных исключениях».
  2. Работа с аяксом без лишней головной боли (в обход «битриксовой» технологии).
  3. Установка ОГ-тегов для соцсетей.
  4. Наследование параметров компонентов с возможностью модификации.

Базовые битриксовые компоненты

Всё это должно быть. В смысле, это должно быть написано один раз и применяться на всём проекте. Не копи-пастом, а в виде дочерних классов.

Встречайте «Базовые битриксовые компоненты» — первые, по-настоящему функциональные компоненты для «Битрикса».

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

Сборка включает в себя два основополагающих абстрактных компонента: basis.router (для комплексных компонентов) и basis (для всех остальных), и компоненты elements.* для работы с элементами инфоблока. У компонентов есть три точки входа, через методы:

  1. executeProlog() — выполняется в начале работы компонента, после подключения модулей, установки параметров и заголовков. Результаты метода не кешируются.
  2. executeMain() — основная логика компонента, все ключевые операции производятся в этом методе. Если в параметрах компонента передан ключ CACHE_TYPE не равный «N», результаты метода буду закешированы.
  3. executeEpilog() — выполняется после подключения шаблона компонента. Результаты не кешируются.

Маленький пример структуры класса, отнаследованного от базового компонента:

<?php

namespace Components\Project;

use Components\Basis;


if(!defined('B_PROLOG_INCLUDED')||B_PROLOG_INCLUDED!==true)die();

\CBitrixComponent::includeComponentClass('basis:basis');


class Test extends Basis\Basis
{
    // Типаж для работы с элементами инфоблоков и различные соцфичи
    use Elements;

    // Модули, которые будут подключены
    protected $needModules = array('iblock');

    // Указываем условия для проверок и приведения параметров
    protected $checkParams = array(
        'IBLOCK_TYPE' => array('type' => 'string'),
        'IBLOCK_ID' => array('type' => 'int')
    );

    public function onPrepareComponentParams($params)
    {
        // Устанавливаем свои параметры, если необходимо

        return $params;
    }

    protected function executeProlog()
    {
        // Выполняем действия в самом начале работы компонента. 
        // Например, можно сохранить какие-нибудь данные, отправленные
        // из формы
    }

    protected function executeMain()
    {
        // Основная логика, метод кешируется. Например, делаем выборку
        // из инфоблока
    }

    protected function executeEpilog()
    {
        // Операции, производимые после подключения шаблона компонента
    }
}

Кроме того, компонент elements.list вызывает на каждой итерации цикла обработки результатов запроса элементов инфоблока метод prepareElementsResult(). С помощью этого метода в дочерних компонентах можно модифицировать обработку результатов выборки: удалять, изменять и добавлять поля, производить какие-либо операции. Метод должен вернуть либо массив полей элемента, либо false для пропуска итерации.

public function prepareElementsResult($element)
{
    if ($element['NAME'] === 'BBC')
    {
        // Пропускаем итерацию, результат не попадёт в arResult
        return false;
    }

    // Обрезаем описание для анонса
    $element['PREVIEW_TEXT'] = substr($element['PREVIEW_TEXT'], 0, 100);

    return $element;
}

Все методы классов задокументированы, компоненты серии elements.* — хороший пример, демонстрирующий возможности сборки, так что смело открывайте свои «идэешки» и наслаждайтесь красотой и умениями ББК. Полноценной документации в онлайне нет, пока только краткое техописание.

Пишите, предлагайте, критикуйте и отправляйте пул-реквесты. Вэлкам!

Базовые битриксовые компонентыβ

P. S. В «Битриксе» много корпоративщины, коммерции. Я не говорю, что это плохо или хорошо, просто пришло время разбавить её. Я приглашаю всех желающих принять участие в развитии ББК, пишите мне на почту или в комментарии.

2015   1С-Битрикс   ББК   веб-разработка

Многосайтовость в «Битриксе»

Делюсь опытом разработки многосайтов.

Подкаталоги в php_interface

«Битрикс» позволяет создавать для каждого сайта свой php_interface, со своим init.php и подключаемыми файлами. Что это даёт? Как известно, все файлы, подключаемые в init.php, подгружаются на каждом хите. Вынеся всю логику в каталог отдельного сайта, мы снимем необходимость прогружать эти файлы в других сайтах. Хороший тон — использовать эту возможность всегда, даже когда разрабатывается один сайт, потому что никто не гарантирует, что, скажем, через год на том же ядре не появятся новые проекты.

Из консоли идентификатор сайта не определяется и, как следствие, подкаталог не подгружается. Консольные скрипты можно выносить в корневой php_interface, но лучше всего — в модули.

В документации можно почитать о порядке выполнения страницы.

Шаблоны компонентов

Правильнее складывать шаблоны компонентов в текущий шаблон сайта. Это своего рода неймспейсы, привносящие ясность о принадлежности шаблона компонента к конкретному сайту. С таким подходом:

  • не возникнет необходимости городить избыточное название шаблона компонента (напр., bitrix:news) для нового сайта (ага, один news уже был кастомизирован для первого сайта);
  • при редизайне сайта нужно просто создать новые шаблоны сайта и компонентов, не затирая старые, не городя названия в стиле «news_v2»;

Шаблоны компонентов, используемые в разных шаблонах сайтов можно размещать в /local/templates/.default/. Для удобства его принадлежность к конкретному проекту я выделяю приставкой в начале названия: (project.template_name).

Сортировка сайтов

Со многими, наверное, был такой случай: создал сайт в «Битриксе», зашёл на него, а показывается другой. Дебажишь константу SITE_ID, а в ней совсем не то. Проверяешь адреса, настройки — всё ОК. Но сайт не определяется. А дело-то всё в порядке сортировки сайтов — субдомены должны иметь индекс сортировки выше, чем основные сайты. И ещё нужно расставлять приоритет в зависимости от названия: у abs.site.ru выше, у qwe.site.ru — ниже. Прямо как в настройках «Апача».

«Адреса сайтов»

Частенько бывает нужно перелинковать сайты друг на друга, типичный пример: site.ru и job.site.ru. Создавать лишние константы — плохо, особенно, когда для этой задачи в «Битриксе» почти всё есть. В настройках сайта через админку можно указать УРЛ сервера и получить эти данные с помощью метода \Bitrix\Main\SiteTable::getList(). Вот только указанный метод обращается напрямую к БД. Решить эту проблему можно с помощью модуля «Адреса сайтов», который хранит информацию в дисковом кеше и имеет удобное АПИ для работы с ней.

И ещё раз о php_interface

Лично меня, когда я был «маленьким битриксоидом», пугали модулями. Мол, там всё непросто, и лучше с ними не связываться. Действительно, там есть свои особенности, если делается решение для «Маркетплейса». Но фактически, модуль — тот же самый компонент, только круче и интереснее.

Модуль быстро собирается, особенно, если делать это из заготовленных шаблонов. В модуле поддерживается автозагрузка классов, есть опции (редактируются через админку) и всё то же самое, что и в каталоге php_interface. Только структурированное.

Есть мнение, что создание модуля должно быть оправдано. Я считаю иначе: должно быть оправдано использование php_interface.

2014   1С-Битрикс   веб-разработка

«Адреса сайтов»

В многосайтовых разработках одного проекта на «Битриксе» периодически возникает необходимость в перелинковке сайтов. Типичные примеры: иноязычные версии сайта; подсайты проектов, дочерних компаний, размещаемые на других доменах. Простое решение — создать константы. Удобное решение — использовать данные из БД, хранящиеся в настройках сайтов. «Битрикс» умеет отдавать эти данные только после непосредственного обращения к БД. Понятное дело, такой расклад неприемлем.

center

Так были созданы «Адреса сайтов» — решение, облегчающее жизнь разработчиков. АПИ модуля умеет отдавать данные о всех сайтах системы, и, при необходимости, генерировать на каждом хите динамические константы. Информация забирается из файлового кеша, обращения к БД происходят только при добавлении нового или обновлении старых сайтов (ну и при устаревании кеша, разумеется).

В зоне Bitrix\Siteurl находится класс Sites, в котором доступны сл. методы:

getUrl();
getName();
getDomain();
getList();

У всех необязательный параметр $siteId по-умолчанию равен идентификатору текущего сайта. Метод getList() имеет второй параметр — $field, позволяющий ограничивать выборку.

use Bitrix\Siteurl;

Bitrix\Main\Loader::includeModule('nik.siteurl');

/**
 * Вернёт массив всех сайтов со всеми полями:
 * [s1] => array(NAME => Сайт 1, DOMAIN => site.ru, URL => http://site.ru)
 * [s2] => array(NAME => Сайт 2, DOMAIN => eng.site.ru, URL => http://eng.site.ru)
 * [s3] => …
 */
Sites::getList();

/**
 * Вернёт массив всех сайтов и поле «Название веб-сайта»:
 * [s1] => Сайт 1
 * [s2] => Сайт 2
 * [s3] => …
 */
Sites::getList(false, 'NAME');

/**
 * Вернёт массив всех полей сайта с идентификатором s2:
 * array(NAME => Сайт 2, DOMAIN => eng.site.ru, URL => http://eng.site.ru)
 */
Sites::getList('s2');

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

S1_NAME
S1_DOMAIN
S1_URL

IT_NAME
IT_DOMAIN
IT_URL

Короче, жизнь теперь станет проще.

Скачать с маркетплейса

2014   1С-Битрикс   веб-разработка

«Элементарий». Особенности создания модуля для «1С-Битрикса»

Сегодня в маркетплейсе «Битрикса» появился «Элементарий» — мой пилотный проект. Название модуля отражает его простоту и область применения.

Первая версия показывает в формах редактирования элементов инфоблоков информацию из журнала событий — кто создал, сколько раз, кем и когда был изменён элемент. На случай, если по каким-то причинам вывод данных из журнала событий не подходит, можно использовать второе свойство — «Кто создал / изменил элемент?» Оно базируется на данных таблицы инфоблока.

Публикация решения в маркетплейсе

В целом, механизм публикации довольно-таки удобный. Вы просто заполняете форму в личном кабинете, читаете условия и напоминания. Комментарии от модераторов и клиентов тоже можно читать в ЛК. Однако, ложку дёгтя вносит ограничение поля описания контактов разработчика — не менее 100 символов (рукалицо.джипег).

Не забывайте, что клиенты могут установить ваше решение на старые версии «Битрикса», не имеющие в себе ядра Д7. В установочных файлах применяйте классы только старого ядра.

Модерация

Решения в маркетплейсе тестируются в три этапа.

  1. Автоматически проверяется структура и наличие ключевых переменных.
  2. Модератор устанавливает и проверяет «вменяемость» решения.
  3. Далее, судя по двухнедельным ожиданиям, «битриксоиды» проверяют код.

Подводные камни

Автопроверка ищет в install/index.php строку var $MODULE_ID. Увы, но придётся смириться с пережитком прошлого, объявление через public маркетплейс не примет.

В конструкторе класса установочного файла при подключении version.php используйте функцию include без суффикса _once, иначе информация о модуле не будет подгружаться в разделе «Обновление решений», что вызовет ошибку с кодом Ux11.

Скачать с маркетплейса

2014   1С-Битрикс   веб-разработка