Download the PHP package proklung/bitrix-core-symfony without Composer

On this page you can find all versions of the php package proklung/bitrix-core-symfony. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of proklung/bitrix-core-symfony

Informations about the package bitrix-core-symfony

Базовый функционал для внедрения Symfony в Битрикс

Установка

composer.json:

Инициализация

В init.php:

Для обеспечения "преемственности" (похожести) с оригиналом можно задать путь к файлу конфигурации (скажем, bundles.php) бандлов вторым (необязательным) параметром конструктора.

Переменные среды

Предполагается, что переменные среды к моменту инициализации контейнера уже загружены тем или иным способом.

Значимые переменные среды:

Если переменные среды не заданы, то с помощью класса Prokl\ServiceProvider\LoadEnvironment их можно загрузить.

Скажем, в init.php, перед инициализацией контейнера:

Конфигурирование

1) Опция compile.container в подтягиваемом конфиге - компилировать ли контейнер в файл. Если не задана, то "нет, не компилировать". Имеет смысл для окружения, не равного "dev". Т.е. опция управляет дампированием контейнера на проде.

Место, где хранятся дампы контейнеров: <значение переменной контейнера kernel.cache_dir>/<SITE_ID>/containers

Пути к кэшу и логам

Определяются классом AppKernel. По умолчанию:

Чтобы это изменить нужно отнаследоваться от класса AppKernel и переопределить несколько переменных:

(второй вариант - отнаследоваться от AppKernel и переопределить методы getCacheDir и getLogDir).

Изменить через наследование класс ядра:

Второй вариант - отнаследоваться от ServiceProvider и заменить метод getPathCacheDirectory своей логикой.

Поддержка бандлов

Файл конфигурации - /config/standalone_bundles.php. Этот путь можно изменить через конструктор.

Папка, где лежат конфигурации - /local/configs. Конфигурации бандлов - /local/configs/packages.

Проблема с приватными сервисами

Согласно концепции Symfony все сервисы (в идеале) должны быть приватными и инжектиться. Но в кастомном случае часто нужно получать их через хелпер-сервис-локатор. Для превращения нужных сервисов в публичные предлагается такое решение. В общем разделе параметров контейнера появилась опция publicable_services:

После компиляции контейнера приватный сервис snc_redis.default станет публичным.

Сепаратные микро-контейнеры

Отдельные контейнеры - со своим конфигом, полностью изолированные (для модулей и т.п.).

Пример класса ExampleAppKernel:

Где надо - инициализация:

Хэлпер container заточен под работу с микро-сервис-провайдерами:

Автозапуск сервисов

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

Поддерживается приоритет запуска. Тогда надо так:

Сервис с приоритетом 100 запустится раньше сервиса с приоритетом 200.

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

Тэг: bitrix.events.init.

1) event - название события. 2) method - метод-обработчик в сервисе 3) module - модуль события 4) sort - сортировка

Автоматическое подхватывание расширений Twig

Тэг twig.extension.

Сервисы по умолчанию

Автоматом регистрируются сервисы:

Хэлперы

1) container() - отдает экземпляр контейнера (выступает в роли сервис-локатора):

2) delegatedContainer() - отдает экземпляр манипулятора (реализующего интерфейс Symfony\Component\DependencyInjection\ContainerInterface) делегированными контейнерами.

В контейнере делегированный контейнер помечается тэгом delegated.container (их может быть сколь угодно много):

Делегированный контейнер - автономный контейнер, сформированные в модуле, плагине и тому подобных местах.

Импорт в контейнер сервисов битриксового сервис-локатора

Автоматом подтягиваются в контейнер сервисы из битриксового сервис-локатора. Формат, секция services из /bitrix/.settings.php и /bitrix/.settings_extra.php. Также загрузчик пробегает по списку установленных модулей и подцепляет их тоже.

Для отдельных сервис-контейнеров (отнаследованных от AbstractStandaloneServiceProvider) такая загрузка не производится.

Если эта фича не нужна, то нужно отнаследоваться от ServiceProvider и заглушить метод loadBitrixServiceLocatorConfigs.

BitrixSettingsDiAdapter

Адаптер-импортер настроек битриксового сервис-локатора (.settings.php) в симфонический контейнер.

Считываются конфиги в Битриксе как-то так:

Совместимость с новым механизмом битриксовых роутов

С версии 21.400.0 (от 16.07.2021) главного модуля в Битриксе появился сносный роутер.

Чтобы использовать в этом контексте контейнер нужно:

Это важно, т.к. без этого сервис-провайдер завалится на стадии подключения файла с роутами; они подключаются раньше инициализации ядра. И, если эту проблему еще можно решить, отключив проверку классов сервисов на существование, то запускающиеся автоматом сервисы по тэгу service.bootstrap обломятся стопроцентно.

Класс битриксового контроллера (ExampleBitrixActionController) с заточкой под DI:

Описывается сервисом так:

Ничего революционного, но так можно получить нормально-сконфигурированный класс контроллера, со всякими зависимостями и т.п.

All versions of bitrix-core-symfony with dependencies

PHP Build Version
Package Version
Requires php Version >=7.4 | ~8
symfony/dependency-injection Version ^4.4 || ^5.0
symfony/http-kernel Version ^4.4 || ^5.0
symfony/config Version ^4.4 || ^5.0
symfony/framework-bundle Version ^4.4 || ^5.0
symfony/filesystem Version ^4.4 || ^5.0
symfony/routing Version ^4.4 || ^5.0
symfony/http-foundation Version ^4.4 || ^5.0
symfony/event-dispatcher Version ^4.4 || ^5.0
symfony/property-access Version ^4.4 || ^5.0
symfony/serializer Version ^4.4 || ^5.0
symfony/console Version ^4.4 || ^5.0
symfony/cache Version ^4.4 || ^5.0
symfony/http-client Version ^4.4 || ^5.0
symfony/proxy-manager-bridge Version ^4.4 || ^5.0
symfony/validator Version ^4.4 || ^5.0
symfony/dotenv Version ^4.4 || ^5.0
symfony/yaml Version ^4.4 || ^5.0
symfony/expression-language Version ^4.4 || ^5.0
twig/twig Version ~1.0 || ~2 || ~3
proklung/base-exception Version ^1.0
symfony/psr-http-message-bridge Version ^2.1
nyholm/psr7 Version ^1.4
guzzlehttp/psr7 Version ^1.8 || ^2
vlucas/phpdotenv Version 3.* || 4.*
psr/container Version 1.0.*
psr/http-client Version ^1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package proklung/bitrix-core-symfony contains the following files

Loading the files please wait ....