Для разработчиков

PHP-хуки

Обновлено

Плагин расширяет приложение через хуки: подписывается на событие и получает управление в нужный момент. Ниже — полный список точек расширения.

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

Жизненный цикл заявки

ХукКогда срабатываетПараметры
request_before_createДо сохранения заявкиform, fields, values, request_data
request_after_createПосле сохраненияrequest_id, form, fields, values, contact_id
request_before_status_changeДо смены статусаrequest_id, old_status_id, new_status_id, request
request_after_status_changeПосле смены статусаrequest_id, old_status_id, new_status_id, request
request_before_deleteДо удаленияrequest_id, request
request_after_deleteПосле удаленияrequest_id, request

Уведомления

ХукКогда срабатываетПараметры
notification_before_sendДо отправки письмаform, request_id, fields, values, emails, subject, body
notification_after_sendПосле отправкиform, request_id, emails, success

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

Форма и проверка значений

ХукКогда срабатываетПараметры
form_before_renderПеред выводом полейform, context, fields (по ссылке)
submission_before_validateЗначения получены, проверка ещё не шлаform, fields, values (ссылка), hidden_field_ids (ссылка)
compute_fieldsПри отправке, до проверкиform, fields, values (по ссылке)
field_validateВо время проверкиfield, value, form
form_exportФорма выгружается в файлform, fields, export (по ссылке)
form_importФорма создана по файлуform_id, form, data, field_map, warnings (по ссылке)
file_before_uploadДо сохранения файлаfield, file, request_id
file_after_uploadПосле сохранения файлаfield, file_path, original_name, request_id

form_before_render

Вызывается из единой точки подготовки полей, через которую проходят все входы вывода. Какой именно — говорит context: inline, modal, quiz или api.

Обработчик дописывает полю атрибуты, и они попадают в разметку:

public function formBeforeRender($params)
{
    foreach ($params['fields'] as &$field) {
        if ($field['type'] === 'phone') {
            // на сам контрол
            $field['attributes']['data-mask'] = '+7 (999) 999-99-99';
            // на обёртку поля
            $field['wrapper_attributes']['data-col'] = 'left';
        }
    }
    unset($field);
}

Значения экранируются при печати. true печатается атрибутом без значения, null и false не печатаются вовсе. Массив полей передан ссылкой внутри параметров, поэтому объявлять &$params не нужно.

submission_before_validate

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

Через параметр hidden_field_ids плагин может объявить своё поле скрытым — тогда оно не проверяется и не попадает в заявку, ровно как поле, спрятанное условием:

public function submissionBeforeValidate($params)
{
    $params['hidden_field_ids'][] = (int) $field['id'];
}

Список приходит уже заполненным условиями приложения; чужие номера и мусор отбрасываются.

field_validate

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

Обязательность и общие ограничения — длину, шаблон — приложение проверяет само, до хука.

form_export и form_import

Приложение не знает о настройках плагинов, поэтому свои значения — привязку к воронке CRM, источник тикетов, поле с суммой сделки — плагин выгружает и восстанавливает сам.

При импорте плагин получает field_map — карту соответствия номеров полей на источнике и здесь. Без неё ссылку плагина на поле после переноса не починить.

Точка, которой нет

form_after_create объявлен, но не вызывается ниоткуда — ни при создании формы, ни при копировании. Не стройте на нём логику: подписчик не сработает.