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.

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?

Informations about the package wp-core-symfony

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

Установка

composer.json:

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

В wp-config.php:

В functions.php темы:

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

Значимые переменные окружения

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

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

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

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

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

Чтобы это изменить нужно отнаследоваться от класса 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 с двумя методами:

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

Автоматом регистрируются несколько сервисов:

Хэлперы

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

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

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

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


All versions of wp-core-symfony with dependencies

PHP Build Version
Package Version
No informations.
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/wp-core-symfony contains the following files

Loading the files please wait ....