Add Container info page

Webprofiler (submodule of devel) already has a widget that show all the services defined, isn't enough?

I really think that this should be available, in a basic format as the Entity and Field information are, in the Devel module itself.

Ok, just a couple of quick fixes:

1. +++ b/src/Controller/DevelController.php
   @@ -232,4 +232,24 @@ class DevelController extends ControllerBase {
   +    $container_definition = \Drupal::service("kernel")->getCachedContainerDefinition();
   

   kernel service should be injected

2. +++ b/src/Controller/DevelController.php
   @@ -232,4 +232,24 @@ class DevelController extends ControllerBase {
   +    foreach ($container_definition["services"] as $name => $definition) {
   +      $container_definition["services"][$name] = unserialize($definition);
   

   Can we use single quotes here?

Then we should wait for Moshe and willzyx to approve this.

Why your patch finds 608 services (on my test site) and Webprofiler 615?

@tlyngej: I love it! Some feedback on your patch:

• Why just the services ($container_definition['services']) and not the entire $container_definition? There is some useful stuff in the $container_definition['parameters'] for example.
• Could the list of services be sorted alphabetically? It would make the list easier to browse.

@lussoluca - a comparison with the web profiler widget:

• The services widget from web profiler isn't enabled by default. A minor point, but I didn't know it was available. The new page at devel/service/info automatically inserts into the Development menu block, the Druplicon menu provided by admin_toolbar_tools module, and the toolbox menu near the start of web profiler.
• The service info page from this patch lets me see more information than webprofiler does. For example, the listing at devel/service/info identifies the factory method and arguments for a service.
• Webprofiler identifies which (and how many) services are initialized for a given page load, which isn't really in scope here.

Why your patch finds 608 services (on my test site) and Webprofiler 615?

Webprofiler also shows private services. I should print this information somewhere so developers know that those services cannot be used directly (#2828361: Add more information to services widget).

@tlyngej thanks for contributing!
I'm ok with the changes but IMHO the issue needs some work

1. why not create a new controller (ServiceInfoController?) instead of polluting DevelController with the methods for all the functionalities?

2. +++ b/src/Controller/DevelController.php
   @@ -232,4 +260,40 @@ class DevelController extends ControllerBase {
   +    $output['parameters'] = array(
   ...
   +      'content' => array(
   ...
   +    $output['services'] = array(
   

   can we use short array syntax?

3. +++ b/src/Controller/DevelController.php
   @@ -232,4 +260,40 @@ class DevelController extends ControllerBase {
   +    $output['services'] = array(
   +      '#type' => 'details',
   +      '#title' => $this->t('Services'),
   +      'content' => array(
   +      '#markup' => kpr($container_definition['services'], TRUE),
   +      ),
   +    );
   

   we can inject devel.dumper service and use $this->dumper->exportAsRenderable($var) instead of manually create the render array and use kpr()

4. and very important... we need test coverage for this!! :)

also (not blocking and to be explored) we could think to show the services/parameters in a table with js quick filter for a simpler and better UX.. If we do this what kind of info we will loose?

So in my opinion, this feature is done, ready for a review.

and I have reviewed it :)

I agree that having all of the pages existing in one controller is about to get out of hand, but that's how it currently works.

Have all the methods in a single controller looks very wrong to me and since we choose to gradually split DevelController for a better organization and for consistency (see #2792227: Move entity debug methods to a dedicated controller) we should stop to polluting DevelController with the methods for all the functionalities.

What you are suggesting requires a lot more work, and a dedicated issue.

if we add NEW functionalities they should be maintainable and with test coverage!

Since we are adding a new functionality I do not see why not do the things properly :)

If you need help with the suggested changes I'm glad to help you

A lot better :)
a quick review

1. +++ b/src/Controller/ServiceInfoController.php
   @@ -0,0 +1,86 @@
   +  public function __construct(DrupalKernel $kernelService, DevelDumperManager $dumper) {
   

   we need to use interfaces for the DI not the concrete classes

2. +++ b/src/Controller/ServiceInfoController.php
   @@ -0,0 +1,86 @@
   +    $output['parameters'] = [
   +      '#type' => 'details',
   +      '#title' => $this->t('Parameters'),
   +      'content' => $this->dumper->exportAsRenderable($container_definition['parameters']),
   +    ];
   ...
   +    $output['services'] = [
   +      '#type' => 'details',
   +      '#title' => $this->t('Services'),
   +      'content' => $this->dumper->exportAsRenderable($container_definition['services']),
   +    ];
   

   since some of devel plugins already wrap the output in a detail element (see DoctrineDebug and DrupalVariable) when you use ::exportAsRenderable() not sure if it is the best solution..

3. +++ b/src/Tests/DevelServiceInfoTest.php
   @@ -0,0 +1,40 @@
   +class DevelServiceInfoTest extends WebTestBase {
   +
   +  /**
   +   * Modules to enable.
   +   *
   +   * @var array
   +   */
   +  public static $modules = ['devel'];
   +
   +  /**
   +   * Does the page exist and load the expected two sets of output?
   +   */
   +  public function testServiceInfoPage() {
   +
   +    $web_user = $this->drupalCreateUser([
   +      'access devel information',
   +    ]);
   +
   +    $this->drupalLogin($web_user);
   +
   +    $this->drupalGet('devel/service/info');
   +    $this->assertResponse(200);
   +    $this->assertText('Service info');
   +    $this->assertText('service_container');
   +    $this->assertText('factory.keyvalue');
   +
   +  }
   +
   +}
   

   probably we need to expand a bit the test coverage

Good job @tlyngej

Do you want this patch to include an interface for controllers (DevelControllerInterface)

no absolutely..

+++ b/src/Controller/ServiceInfoController.php
@@ -0,0 +1,86 @@
+  public function __construct(DrupalKernel $kernelService, DevelDumperManager $dumper) {

this should be changed to use the interfaces. In this way the ServiceInfoController is not coupled with concrete services implementation and the injected services can be swapped without problems
DrupalKernel => DrupalKernelInterface
DevelDumperManager => DevelDumperManagerInteface

Not sure I completely follow you there. Can you elaborate what you mean?

Try to set DrupalVariable or DoctrineDebug plugin as default dumper and visit the service info page

there are two nested detail elements because some of devel plugins already wrap the output in a detail element (see DoctrineDebug and DrupalVariable) when you use ::exportAsRenderable()

Any clues on what more to test? There isn't much functionality on the page.

probably we can test that the dump of what we expect is present on the page

Also I think that we can display also the aliases retrieved by the cached container definition ($container_definitions['aliases']) in addition to services and parameters

sorry for the delay.. @tlyngej good job!

I already did test for various strings that I expect to be there, but I threw in some more assertions

Testing dumper output on the web pages is always tricky.. I'm open to expand the test coverage in another issue

In the attached patch I'm exploring another solution.. Show services and parameters in a table with on-fly search instead of dumping the informations. IMHO this can make the informations more readable and the on-fly search make easy to find a specific service (by id class or alias)

Clicking on the Devel operation button the user will be redirected to a page that show the service comuted definition and instacee detail

What do you think?

oops.. and here the patch :P (with test coverage)

I am considering to commit the patch in the coming days.. there is someone who wants to review/test it?

minor changes in tests

Committed and pushed to 8.x. Thanks to all and especially to @tlyngej :)