Или руководство для тех, кто устал хранить API-ключи в разных файлах.
Если вы когда-либо писали модуль для 1С-Битрикс, вы сталкивались с вопросом: «Где хранить настройки?»
Варианты:
- В отдельной таблице — а почему бы и нет, ведь у нас уже 17 таблиц для одной формы.
- В файлах — но тогда придется писать свой класс для работы с таким форматом хранения опций.
- В константах — и такое бывает.
Но в Bitrix есть уже готовый класс для этих целей - COption.
Он есть в ядре, он работает, он — официальный способ хранить настройки.
Сегодня разберём COption: как он работает и как его правильно использовать.
Что такое COption?
COption — это класс ядра Битрикс, отвечающий за централизованное хранение настроек на уровне модулей. Данные храняться в таблице b_option, что позволяет каждому модулю иметь свой набор ключей-значений, которые можно читать, писать и удалять.
Почему это важно?
- Настройки привязаны к модулю, а не к компоненту или странице.
- Поддерживается мультисайтовость — можно задать разные значения для разных сайтов.
- Есть готовые методы для получения и записи значений.
Где хранятся настройки?
Открываем phpMyAdmin и смотрим на таблицу b_option:
| MODULE_ID | NAME | VALUE | SITE_ID |
|---|---|---|---|
| main | upload_dir | /upload | null |
| mymodule | api_key | 12345 | s1 |
| mymodule | debug_mode | Y |
Вот и всё.
Каждая строка — это одна настройка.
MODULE_ID— кому принадлежит.NAME— название параметра.VALUE— значение (в сериализованном виде, если нужно).SITE_ID— для какого сайта.
Основные методы: Get, Set и не только
КлассCOption предоставляет основной набор методов для работы. Примеры:
// Получить строку (или значение по умолчанию)
$key = COption::GetOptionString("mymodule", "api_key", "default123");
// Получить число
$limit = COption::GetOptionInt("mymodule", "items_limit", 10);
// Получить массив (если сохраняли через SetOptionString с сериализацией)
$emails = unserialize(COption::GetOptionString("mymodule", "notify_emails", "a:0:{}"));
// Сохранить
COption::SetOptionString("mymodule", "debug_mode", "Y");
// Удалить
COption::RemoveOption("mymodule", "temp_value");Антипаттерны: что НЕ стоит делать
- Хранить чувствительные данные в открытом виде — пароли, токены и т.д. лучше хранить в зашифрованном виде.
- Использовать
COptionдля настроек компонента — лучше передавать параметры при вызове компонента. - Не валидировать ввод — проверяйте, что пришло в
$_POSTперед сохранением данных в базу. - Не документировать опции — без документации легко случайно задублировать настройки или потратить много времени на поиски нужной опции.
Альтернативы COption
- Пользовательские поля — если настройки привязаны к какому-то объекту: пользователь, сделка, раздел и т.д.
- Отдельная таблица — если настроек много, они иерархические, со сложной логикой выбора.
- Файлы — например,
config.phpс массивом опции. Так же у нас была статья про то как можно хранить свои настройки в файле .settings.php
Но для большинства случаев — COption остаётся лучшим выбором.
Заключение
Класс COption в Bitrix упрощает хранение настроек без дополнительного программирования, однако важно грамотно подбирать опции, которые действительно требуют сохранения таким способом.
Полезный совет: класс COption подходит не только для конкретных модулей, но и для хранения настроек мелких доработок. Чтобы было понятно назначение таких опций, в качестве имени модуля удобно указывать custom или аналогичное обозначение.
Учтите, что при переносе доработок с тестового сервера на рабочий с использованием класса COption, вам потребуется заново задать значения новых настроек.
