Dependencies Service

The dependencies service is a multi-handler service with no implemented action methods. The purpose of this service is to provide a unified way of checking whether dependencies are fulfilled or not. It provides the following public methods:

• get_dependencies for retrieving a list of dependencies from a given handler

• get_missing_dependencies for retrieving a list of missing dependencies from a given handler

• are_dependencies_fulfilled for retrieving a list of boolean values determining whether the dependencies of a given handler are fulfilled or not

You must be used by now to the fact that every service has its quirks. In the case of the dependencies service, the quirk is that it has no default handlers because each handler is supposed to be tied to a particular class instance.

Dependency handlers all implement the DependenciesHandlerInterface and are in essence little more than containers for dependency checkers. Dependency checkers, in turn, all implement the DependenciesCheckerInterface interface.

Let's start from the bottom-up. The utilities module comes pre-packaged with 4 dependencies checker. They are here and, in no particular order, provide checking for the following types of dependencies: PHP extensions, PHP functions, PHP settings, and WP plugins.

At its core, a checker accepts a list of dependencies (each checker might have a different format) and knows how to check whether said dependencies are fulfilled or not. Calling get_missing_dependencies on a checker will return a list of unfulfilled dependencies and calling are_dependencies_fulfilled will return a simple boolean value answering the question.

Continuing with the handlers, the module comes pre-packaged with 2 handlers. The so-called single-checker handler and the so-called multi-checker handler. As their names suggest, the former can store one checker whereas the latter can store multiple checkers. This is a necessary abstraction for supporting the services model.

The difference between the two is that most functions of the single-checker handler will return an array whereas the same functions of the multi-checker handler will return a matrix.

It might come as a surprise to find out the the method are_dependencies_fulfilled of the single-checker handler returns an array with a single entry instead of a simple boolean value. This is done for consistency with the multi-checker handler.

How to use the dependencies service

The dependencies service comes with two traits that try to automagically set things up for you. For example, the InitializeDependenciesHandlersTrait trait lets you define a protected get_dependencies_handlers method inside your class and its output will be automagically registered with the dependencies service on initialization.

Similarly the Dependencies/States namespace contains two traits that let you automagically turn an instance inactive or disabled based on registered dependencies handlers.

Last but not least, the SetupDependenciesAdminNoticesTrait trait goes a step further and will automagically register appropriate admin notices for dependency handlers that influence the activation state of an instance.

Watch out for the SetupDependenciesAdminNoticesTrait trait! It uses the SetupableInactiveTrait which will cause your instance to setup even if inactive. You need to design your code around this.