Идея реализации унифицированного механизма циклической обработки (чистка кешей, логов доступа, таймерные задачи), затрагивающих весь хостинг вместе с разнородными проектами разной степени взаимной реюзабельности признана избыточно сложной и ненужной. Порождается масса проблем и подводных камней, связанных с ограничением взаимного доступа и конфигурированием объектов.
Теперь строго и однозначно - все механизмы обработки работают с раздельными конфигурациями отдельно.
Уточнение на счёт базовых констант:
базовые каталоги системы:
BORS_CORE - как и всегда, путь к ядру системы
BORS_3D_PARTY - путь к расширениям третьих сторон
Каталоги конкретного хостинга/сервера:
BORS_HOST - индивидуальные настройки хостинга/сервера, не требующие синхронизации, например, между тестовым и рабочим сервером. Это могут быть настройки путей ФС, доступа к БД и т.п. Все привязки к хостингу.
BORS_LOCAL - настройки проекта, общие для всех сайтов, например, синхронизируемые между тестовым и рабочим серверами. Общие классы, их конфигурация и т.п. Никаких привязок к хостингу.
Индивидуальный каталог сайта
BORS_SITE - все персональные настройки данного сайта. Никаких привязок к хостингу.
Дополнительно
BORS_APPEND по-прежнему поддерживается, но к использованию не рекомендуется. Это массив отдельных подключаемых разделов. Использовать с осторожностью, так из каталогов, указанных в нём не загружаются config-файлы, что может привести к неработоспособности объектов, которые лежат по этим путям. Не забывайте конфигурировать их в своём разделе.
...
BORS_CORE/tools/cron/loop.sh теперь, поскольку перестал быть глобальным, требует обязательного параметра - списка констант путей. Должен для каждого проекта вызываться отдельно. Например, так:
loop-local.sh
code bash
#!/bin/sh
./loop.sh BORS_CORE=/home/balancer/work/programming/php/bors-core,BORS_SITE=/home/balancer/work/programming/php/bors-aviaport-hg
Параметры перечисляются одной строкой без пробелов.