Stop creating services.yml by default

Created on 7 August 2015, almost 9 years ago
Updated 13 December 2023, 7 months ago

Problem/Motivation

#2543332: Auto-placeholdering for #lazy_builder without bubbling β†’ added an extra key-value pair to the renderer.config container parameter. But, because most site owners don't ever upgrade their sites/default/services.yml to stay in sync with updates to sites/default/default.services.yml, they were left with a services.yml without this new key-value pair. And since services.yml continues to override core.services.yml's container parameters (as intended), this effectively means that the new key-value pair is missing. See #2547127-14: [regression] Empty messages container appearing when a Notice occurs β†’ for details. See https://www.drupal.org/node/2547351 β†’ for the CR that's encouraging people to do the right thing.

This is a specific example, but it points to a larger problem: people are not updating their services.yml file.

Proposed resolution

  • sites/default/services.yml is useless for 99% of sites in its current form: it overrides the defaults in core.services.yml with exactly the same values, because 99% of sites don't modify sites/default/services.yml.
  • But, when the defaults (in sites/default/default.services.yml) are updated, problems occur.
  • So: stop creating sites/default/services.yml by default.
  • It'd also simplify the installation process: no need for the user to copy default.services.yml to services.yml and mess with file system permissions.
  • Have the services.yml be an opt-in thing: use file_exists() to determine whether services.yml's container parameters should be used when building the container. (This file_exists() check would only happen during container rebuilds.)

Other solutions discussed: A) have everything in default.services.yml and hence also services.yml be commented; B) have services.yml be merged instead of overridden (this is supported by Symfony, we never actually configured it).

Remaining tasks

Implement it.

User interface changes

None.

API changes

None.

Data model changes

None.

πŸ“Œ Task
Status

Fixed

Version

8.0 ⚰️

Component
BaseΒ  β†’

Last updated 29 minutes ago

Created by

πŸ‡§πŸ‡ͺBelgium Wim Leers Ghent πŸ‡§πŸ‡ͺπŸ‡ͺπŸ‡Ί

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.

  • πŸ‡©πŸ‡ͺGermany osopolar πŸ‡©πŸ‡ͺ GER 🌐

    The question in #5 from @almaudoh was not answered. AFAICS It's not necessary to copy the complete default.services.yml to services.yml but it might be necessary to copy/set all options for a parameter and not just the one which should get overridden.

    Example:

    Set cookie_lifetime: 0 with following services.yml:

    parameters:
      session.storage.options:
        cookie_lifetime: 0
    

    After setting above code in services.yml and rebuilding cache the output of drush php:eval "var_export(\Drupal::getContainer()->getParameter('session.storage.options')) is:

    array (
      'cookie_lifetime' => 0,
    )

    Which is different to the output with no services.yml which is:

    array (
      'gc_probability' => 1,
      'gc_divisor' => 100,
      'gc_maxlifetime' => 200000,
      'cookie_lifetime' => 2000000,
      'cookie_samesite' => 'Lax',
      'sid_length' => 48,
      'sid_bits_per_character' => 6,
    )
    

    Therefore I assume that it might be necessary to define all options below for one parameter, at least if no defaults are defined by the corresponding service:

    parameters:
      session.storage.options:
        gc_probability: 1
        gc_divisor: 100
        gc_maxlifetime: 200000
        cookie_lifetime: 0
        cookie_samesite: Lax
        sid_length: 48
        sid_bits_per_character: 6
    

    Is that assumption right?

    Anyway, looking at \Drupal\Core\Session\SessionConfiguration::__construct() shows that defaults are defined, so at least in this case the missing options shouldn't be problematic.

Production build 0.69.0 2024