Download the PHP package proklung/wp-core-symfony without Composer
On this page you can find all versions of the php package proklung/wp-core-symfony. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Informations about the package wp-core-symfony
Базовый функционал для внедрения Symfony в Wordpress
Установка
composer.json:
Инициализация
В wp-config.php
:
В functions.php
темы:
Для обеспечения "преемственности" (похожести) с оригиналом можно задать путь к файлу конфигурации
(скажем, bundles.php
) бандлов четвертым (необязательным) параметром конструктора.
Значимые переменные окружения
APP_ENV
- код окружения (dev, prod, test и т.д.)APP_DEBUG
- режим отладки
Конфигурирование
1) Опция compile.container
в подтягиваемом конфиге - компилировать ли контейнер в файл. Если не задана, то "нет, не компилировать".
Имеет смысл для окружения, не равного "dev". Т.е. опция управляет дампированием контейнера на проде.
Место, где хранятся дампы контейнеров: <значение переменной контейнера kernel.cache_dir>/symfony-app/containers
Пути к кэшу и логам
Определяются классом AppKernel
. По умолчанию:
- путь к кэшу (
kernel.cache_dir
) -/wp-content/cache
- путь к логам (
kernel.logs_dir
) -'/../../logs'
(два уровня выше DOCUMENT_ROOT - особенности используемой сборки Битрикс)
Чтобы это изменить нужно отнаследоваться от класса AppKernel
и переопределить несколько переменных:
(второй вариант - отнаследоваться от AppKernel
и переопределить методы getCacheDir
и getLogDir
).
Изменить через наследование класс ядра:
Второй вариант - отнаследоваться от ServiceProvider
и заменить метод getPathCacheDirectory
своей логикой.
Поддержка бандлов
Файл конфигурации - /config/standalone_bundles.php
. Этот путь можно изменить через конструктор.
Папка, где лежат конфигурации - /config
. Конфигурации бандлов - /config/packages
.
Проблема с приватными сервисами
Согласно концепции Symfony все сервисы (в идеале) должны быть приватными и инжектиться. Но в кастомном случае
часто нужно получать их через хелпер-сервис-локатор. Для превращения нужных сервисов в публичные предлагается
такое решение. В общем разделе параметров контейнера появилась опция publicable_services
:
После компиляции контейнера приватный сервис snc_redis.default
станет публичным.
Сепаратные микро-контейнеры
Отдельные контейнеры - со своим конфигом, полностью изолированные (для модулей, плагинов и т.п.).
Пример класса ExampleAppKernel
:
Где надо - инициализация:
Хэлпер container
заточен под работу с микро-сервис-провайдерами:
Автозапуск сервисов
Чтобы сервис запустился автоматически после инициализации контейнера, он должен быть помечен тэгом service.bootstrap
.
Поддерживается приоритет запуска. Тогда надо так:
Сервис с приоритетом 100 запустится раньше сервиса с приоритетом 200.
Автоматическая подвязка на хуки Wordpress
Тэг: custom.events.init
.
1) type
- add_action, add_filter & etc По умолчанию: add_action
.
2) event
- название хука.
3) method
- метод-обработчик в сервисе
4) priority
- приоритет
Автоматическая регистрация типов постов
Тэг: post.type
.
Реализует интерфейс PostTypeDataInterface
с двумя методами:
getNameTypePost
- название типа постаgetRegistrationData
- массив с традиционными для объявления типа поста данными. Типа такого:
Сервисы по умолчанию
Автоматом регистрируются несколько сервисов:
service_container
(и alias) - сервис-контейнер целикомapp.request
- конвертор глобалов в Requestcustom.post.type.registrator
- регистратор кастомных типов постов в Wordpress- синонимы сервиса
kernel
. delegated_container_manipulator
- манипулятор делегированными контейнерами.
Хэлперы
1) container()
- отдает экземпляр контейнера (выступает в роли сервис-локатора):
2) delegatedContainer()
- отдает экземпляр манипулятора (реализующего интерфейс Symfony\Component\DependencyInjection\ContainerInterface
)
делегированными контейнерами.
Делегированный контейнер - автономный контейнер, сформированные в модуле, плагине и тому подобных местах.
В контейнере он помечается тэгом delegated.container
(их может быть сколь угодно много):