This project is not covered by Drupal’s security advisory policy.

Service Container is an API module based on ctools to enable a Drupal 7 quick and easy lightweight service container with 100% unit test coverage.

It is very similar in syntax to a Symfony container, but was written from scratch as a Symfony Dependency was not wanted - using some of Drupal 8 Core and Component directly. They will likely depend on a drupal8core project in the future - but for now the copy is fine.

This allows to use an extensible service container (like in Drupal 8) and write modules in Drupal 7 as if they were using Drupal 8.

The main benefit is being able to use unit testing.

service_container uses PHP Unit and travis.yml, but the tests and a composer.json are isolated in the tests/ directory, so no vendor or composer multi map is needed by default.

It was originally written for the render_cache module, but since then others have expressed interest in using it, so this will split it out.


How does it work

There is two ways:

a) Add [module].services.yml like in Drupal 8 and depend on service_container_symfony submodule. => done

b) Register a ServiceContainer/ServiceProvider CTools plugin:

You register your CTools plugins normally and reference service_container, ServiceProvider plugin.

Then you implement:

public function getContainerDefinition() {


There is also an altering function that can be seen as the conterpart to a compilerPass in Symfony:


The container definition is cached, which means it is possible to use the container (when it is in cache) during hook_boot().

The more you avoid procedural code and use the ModuleHandler to invoke other modular code, the better:

a) You can unit test it.
b) You can do things during hook_boot() or even DRUPAL_BOOTSTRAP_CONFIGURATION.

Registering CTools plugins

By default the service\_container supports CTools discovery, to register your plugins all you need to do is:

    $parameters['ctools_plugins_auto_discovery.render_cache'] = array('render_cache');

And you can then get a plugin via:

    $rcc = \Drupal::service('render_cache.controller')->createInstance('block');

Because the plugin managers implement the whole discovery interface, you can get all definitions with ease.

  $plugins = \Drupal::service('render_cache.controller')->getDefinitions();

Your plugin itself looks like:

cat modules/render_cache_block/src/RenderCache/Controller/

$plugin = array(
  'class' => "\\Drupal\\render_cache_block\\RenderCache\\Controller\\BlockController",
  'arguments' => array('@render_stack', '@render_cache.cache'),

So you can use normal container parameter syntax.

Provides the following services

  • * module handler ('module_handler') and module installer ('module_installer')
  • * service container ('service_container')
  • * database ('database')
  • * key value store ('keyvalue', 'keyvalue.database')
  • * variable, a wrapper for variable_get() / variable_set()
  • * A lock ('lock')
  • * A wrapper for url() / l() ('url_generator', 'link_generator')
  • * Flood, a wrapper for the flood mechanisms
  • * Messenger, a wrapper for displaying messages
  • * Drupal 7 Legacy, a wrapper for accessing the Drupal 7 legacy functions.
  • * More to come...

Differences to Symfony Container?

- Way more light-weight implementation doing only what is necessary for my uses cases.
- Combines the best of the D7 Drupal world (ctools) with advanced caching techniques, therefore no discovery problems.
- API compatible with Symfony DependencyInjection component
- When using service_container_symfony also uses the ContainerBuilder() then dumps that back to PHPArray syntax.

Current limitations / Bugs

- Parameter handling does not work for e.g. class

Project information