← Назад к заметкам

Заметки

Как организовать классы модуля в /local/modules/.../lib

Как организовать классы локального модуля в lib: namespace, автозагрузка, ORM Table-классы и сервисы.

В заметке разбираем тему: Как организовать классы модуля в /local/modules/.../lib. Главное — не переносить решение вслепую с другого портала, а проверить контекст коробки, права, версию модулей и фактические данные.

Задача

Как организовать классы локального модуля в lib: namespace, автозагрузка, ORM Table-классы и сервисы.

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

Ключевые вещи в этой теме: Autoload, namespace, ORM table classes. Именно их стоит проверить первыми, прежде чем менять код.

Как это устроено

В коробке важно отделять штатный API, контекст запуска и прямую правку файлов.

Если код выполняется внутри портала, у него есть контекст Битрикса: подключённые модули, текущий пользователь, права, кеш и события. В CLI, cron или внешнем скрипте часть этого контекста нужно создать вручную.

Для CRM, Диска, календаря, пользовательских полей и модулей лучше начинать со штатных API. Прямые SQL-запросы и правка файлов ядра подходят только как крайняя диагностика, а не как основной способ доработки.

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

Рабочий подход

Сначала зафиксируйте контекст, потом проверяйте API и только после этого меняйте данные.

  • Проверьте, где выполняется код: веб, CLI, cron, агент, обработчик события или iframe приложения.
  • Подключите нужные модули явно и обработайте ситуацию, когда модуль недоступен.
  • Сначала выведите тестовые данные или SQL, затем выполняйте изменение.
  • Для боевого портала добавьте логирование результата и ошибок.

Частые ошибки

Большинство проблем появляется из-за неверного контекста или обхода штатной логики.

  • Код проверяют только под администратором, а потом он не работает у сотрудников.
  • Доработку кладут в /bitrix или в перегруженный init.php вместо /local или модуля.
  • Ошибки не логируются, поэтому после cron, агента или события непонятно, запускался ли код вообще.
  • Данные меняют напрямую, минуя операции, события, права, индексы и кеш.

Минимальный пример

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

/local/modules/itsolution.tools/
  include.php
  lib/
    Service/
      DealSyncService.php
    Event/
      CrmEventHandler.php
    Internals/
      SyncLogTable.php