Enable autoconfiguration for other service tags

Created on 6 May 2023, over 1 year ago
Updated 20 October 2023, about 1 year ago

Problem/Motivation

Follow up from πŸ“Œ Enable service autoconfiguration for core event subscribers Fixed

Steps to reproduce

NA

Proposed resolution

Sub-issues:

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component
BaseΒ  β†’

Last updated about 11 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States smustgrave

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Issue created by @smustgrave
  • Potential other tags to enable this for:

    • Cache contexts
    • Cache bins (potentially)
    • Page cache policies
    • Theme negotiators
    • plugin_manager_cache_clear (which has its own autoconfigure logic anyway already in \Drupal\Core\Plugin\PluginManagerPass::process
    • Param converters

    One interesting question would be: How can the documentation updates be handled. It seems like it would be best to update the documentation once the story is more coherent.

  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Narrowing the scope of this, perhaps this can be a discussion issue and then we open child issues when we have determined tags that could be autoconfigured. I opened πŸ“Œ Use service autoconfiguration for all event subscribers Needs work for the remaining event subscribers.

  • πŸ‡¬πŸ‡§United Kingdom longwave UK

    Implementing this for cache contexts is blocked by πŸ“Œ SessionCacheContext class should implement CacheContextInterface Needs work as not all cache contexts currently implement an interface.

  • Narrowing the scope of this, perhaps this can be a discussion issue and then we open child issues when we have determined tags that could be autoconfigured. I opened #3367455: Use service autoconfiguration for all event subscribers for the remaining event subscribers.

    That sounds like a really good idea!

    Cache contexts

    Look at cache contexts there are actually two interfaces involved:

    1. \Drupal\Core\Cache\Context\CacheContextInterface
    2. \Drupal\Core\Cache\Context\CacheContextsPass

    Interesting enough the services then require to start with cache_context., see \Drupal\Core\Cache\Context\CacheContextsPass,
    but I don't see a reason why this would block autoconfiguration.

    Cache bins (potentially)

    Looking at an example:

      cache.page:
        class: Drupal\Core\Cache\CacheBackendInterface
        tags:
          - { name: cache.bin }
        factory: ['@cache_factory', 'get']
        arguments: [page]
    

    Given the additional arguments, it feels like this could be its own issue to discuss it.

    Page cache policies

    An example of a page cache policy looks like:

        basic_auth.page_cache_request_policy.disallow_basic_auth_requests:
        class: Drupal\basic_auth\PageCache\DisallowBasicAuthRequests
        public: false
        tags:
          - { name: page_cache_request_policy }
    

    This looks like a perfect candidate for autoconfiguration.

    Theme negotiators

    An example looks like this:

        theme.negotiator.ajax_base_page:
        class: Drupal\Core\Theme\AjaxBasePageNegotiator
        arguments: ['@csrf_token', '@config.factory', '@request_stack']
        tags:
          - { name: theme_negotiator, priority: 1000 }
    

    Theme negotiator seem to care all about priorities. This seems to unqualify them for autoconfiguration. We could introduce an additional attribute.

    plugin_manager_cache_clear

    This has its own autoconfigure logic anyway already in \Drupal\Core\Plugin\PluginManagerPass::process

    Param converters

    Looking at an example:

        access_check.entity:
        class: Drupal\Core\Entity\EntityAccessCheck
        tags:
          - { name: access_check, applies_to: _entity_access }
    

    The additional parameter is required. This seems to unqualify them for autoconfiguration. We could introduce an additional attribute.

  • πŸ‡¦πŸ‡ΊAustralia kim.pepper πŸ„β€β™‚οΈπŸ‡¦πŸ‡ΊSydney, Australia

    Added ✨ Add autoconfigure for module loggers Needs review as a sub-issue.

Production build 0.71.5 2024