PHPackages inpsyde/wp-app-container - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. inpsyde/wp-app-container ActiveLibrary[Utility & Helpers](/categories/utility) inpsyde/wp-app-container ======================== DI Container and related tools to be used at website level. 2.0.5(2y ago)41253.5k↑21.6%3[1 issues](https://github.com/inpsyde/wp-app-container/issues)[2 PRs](https://github.com/inpsyde/wp-app-container/pulls)gpl-2.0-or-laterPHPPHP >=7.2.5 < 9CI passing Since Jan 28Pushed 2mo ago6 watchersCompare [ Source](https://github.com/inpsyde/wp-app-container)[ Packagist](https://packagist.org/packages/inpsyde/wp-app-container)[ RSS](/packages/inpsyde-wp-app-container/feed)WikiDiscussions master Synced 1mo ago READMEChangelogDependencies (7)Versions (27)Used By (0) WP App Container ================ [](#wp-app-container) *DI Container and related tools to be used at website level*. [![PHP Quality Assurance](https://github.com/inpsyde/wp-app-container/workflows/PHP%20Quality%20Assurance/badge.svg)](https://github.com/inpsyde/wp-app-container/workflows/PHP%20Quality%20Assurance/badge.svg) --- Table of Contents ----------------- [](#table-of-contents) - [What is and what is not](#what-is-and-what-is-not) - [Concepts overview](#concepts-overview) - [App](#app) - [Service provider](#service-provider) - [Container](#container) - [Env config](#env-config) - [Context](#context) - [Decisions](#decisions) - [Usage at website level](#usage-at-website-level) - [Customizing site config](#customizing-site-config) - [Hosting provider](#posting-provider) - [Locations](#locations) - [Access locations](#access-locations) - [Adjust locations](#adjust-locations) - [Custom locations](#custom-locations) - [Set locations via environment variables](#set-locations-via-environment-variables) - [Usage at package level](#usage-at-package-level) - [Contextual registration](#contextual-registration) - [Package-dependant registration](#package-dependant-registration) - [Providers workflow](#providers-workflow) - [Available service provider abstract classes](#available-service-provider-abstract-classes) - [The case for delayed registration](#the-case-for-delayed-registration) - [Service providers ID](#service-providers-id) - [Composing the container](#composing-the-container) - [Simple service provider example](#simple-service-provider-example) - [Service provider example using any PSR-11 container](#service-provider-example-using-any-psr-11-container) - [Website-level providers](#website-level-providers) - [Providers Package](#providers-package) - [Advanced topics](#advanced-topics) - [Custom last boot hook](#custom-last-boot-hook) - [Building custom container upfront](#building-custom-container-upfront) - [Resolve objects outside providers](#resolve-objects-outside-providers) - [Debug info](#debug-info) - [Installation](#installation) - [Copyright and License](#copyright-and-license) - [Contributing](#contributing) --- What is and what is not ----------------------- [](#what-is-and-what-is-not) This is a package aimed to solve dependency injection container, service providers, and application "bootstrapping", at **application, i.e. website, level**. The typical use case is when building a website for a client, for which we foresee to write several "packages": library, plugins, and theme(s), that will be then "glued" together using Composer. Thanks to this package will be possible to have a centralized dependency resolution, and a quite standardized and consistent structure for the backend of those packages. Technically speaking, right now, there's nothing that prevents the use at package level, however for several reasons, that is a no-goal of this package and no code will be added here to comply with that. This package was not written to be "just a standard", i.e. provide just the abstraction leaving the implementations to consumers, but instead had been written to be a ready-to-use implementation. However, an underlying support for [PSR-11](https://www.php-fig.org/psr/psr-11/) allows for very flexible usage. Concepts overview ----------------- [](#concepts-overview) ### App [](#app) This is the central class of the package. It is the place where "application bootstrapping" happen, where `Service Providers` are registered, and it is very likely the only object that need to be used from the website "package" (that one that "glues" other packages/plugins/themes via Composer). ### Service provider [](#service-provider) The package provides a single service provider interface (plus several abstract classes that partially implement it). The objects are used to "compose" the Container. Moreover, in this package implementation, service providers are (or better, could be) responsible to tell how to *use* the registered services. In WordPress world that very likely means to "add hooks". ### Container [](#container) This is a "storage" that is capable of storing, and retrieve objects by an unique identifier. On retrieval (oftentimes just the first time they are retrieved), objects are "resolved", meaning that any other object that is required for the target object to be constructed, will first recursively resolved in the container, and then injected in the target object before it is returned. The container implementation shipped here is an extension of Pimple, with added PSR-11 support, with the capability to act as a "proxy" to several other PSR-11 containers. Which means that Service Providers can "compose" the dependency tree in the Container either by directly [adding services factories to the underlying Pimple container](https://pimple.symfony.com/#defining-services) or they can "append" to the main container a ready-made PSR-11 container. ### Env config [](#env-config) As stated above, this package targets websites development, and something that is going to be required at website level is configuration. Working with WordPress configuration often means PHP constants, but when using Composer at website level, in combination with, for example, WP Starter it also also means environment variables. The package ships an `SiteConfig` interface with an `EnvConfig` implementation that does nothing in the regard of *storing* configuration, but offers a very flexible way to *read* configuration both from constants and env vars. `Container::config()` method returns and instance of `SiteConfig`. ### Context [](#context) Service providers job is to both add services in the container and add the hooks that make use of them, however in WordPress it often happens that services are required under a specific "context". For example, a service provider responsible to register and enqueue assets for the front-end is not required in backoffice (dashboard), nor in AJAX or REST requests, and so on. Using the proper hooks to execute code is something that can be often addressed, but often not. E.g. distinguish a REST request is not very easy at an early hook, or there's no function or constants that tell us when we are on a login page and so on. Moreover, even storing objects factories in the Container for things we are *sure* are not going to be used is waste of memory we can avoid. The `Context ` class of this package is a centralized service that provides info on the current request. `Container::context()` method returns and instance of Context. Decisions --------- [](#decisions) Because we wanted a ready-to-use package, we needed to pick a DI container *implementation*, and we went for [Pimple](https://pimple.symfony.com/), for the very reason that it is one of the simplest implementation out there. However, as shown later, anyone who want to use a different PSR-11 container will be very able to do so. In the "Concepts Overview" above, the last two concepts ("Env Config" and "Context") are not really something that are naturally coupled with the other three, however, the assumption that this package will be used for WordPress *websites* allow us to introduce this "coupling" without many risks (or sense of guilt): assuming we would ship these packages separately, when building websites (which, again, is the only goal of this package) we will very likely going to require those separate packages anyway, making this the perfect example for the *Common-Reuse Principle*: *classes that tend to be reused together belong in the same package together.* Usage at website level ---------------------- [](#usage-at-website-level) The "website" package, that will glue together all packages, needs to only interact with the `App` class, in a very simple way: ```