Core services individual pages not helpful and jumping to the top result in searches

Created on 9 May 2024, 8 months ago
Updated 29 July 2024, 5 months ago

Problem/Motivation

When searching for FileSystemInterface in 11.x branch, the result doesn't look right. I get a page for the @file_system service in core.services.yml. The class providing this service implements the interface, but I'd expect a page listing all the constants and methods in the interface.

Proposed resolution

The individual detail page for the interface is actually not very helpful, so maybe we can even get rid of it, which will also solve the search issue.

If we keep it, maybe we should keep it out of the search results.

πŸ“Œ Task
Status

Active

Version

2.0

Component

Code

Created by

πŸ‡ͺπŸ‡ΈSpain fjgarlin

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @fjgarlin
  • πŸ‡ΊπŸ‡ΈUnited States tr Cascadia

    This appears to be related to parsing core.services.yml, which also causes other problems that I discuss in πŸ› Many service names do not show up in 11.x documentation Active

    In this case, core.services.yml defines the file_system service like this:

      file_system:
        class: Drupal\Core\File\FileSystem
        arguments: ['@stream_wrapper_manager', '@settings']
      Drupal\Core\File\FileSystemInterface: '@file_system'

    So here, "Drupal\Core\File\FileSystemInterface" is actually a STRING alias for the file_system service - that's what's showing up in your search. It's NOT a class name even though it appears to be one.

    This syntax in core.services.yml is for Symfony to do autowiring of services - Symfony can now automatically inject the file_system service by recognizing either the FileSystem class name or the FileSystemInterface interface name in the constructor arguments to other services, instead of having to specify @file_system in an arguments list for those other services.

  • πŸ‡ͺπŸ‡ΈSpain fjgarlin

    Oh, that explains the weird fully namespaced first choice there, it's the alias that seems to be messing things around. Wondering if we can just ignore aliases in this case, I'm not too familiar with the autowiring from Symfony to know whether it's something relevant that needs to be there, parsed and processed, or if we can just ignore it.

  • πŸ‡ͺπŸ‡ΈSpain fjgarlin

    I'm also wondering if the parsing of those aliases is actually making it ignore the service right below them. That could explain πŸ› Many service names do not show up in 11.x documentation Active .

Production build 0.71.5 2024