Problem/Motivation

Language module alters definition of 'language_manager' service from core.services.yml (see LanguageServiceProvider::alter()):

<?php
  public function alter(ContainerBuilder $container) {
    $definition = $container->getDefinition('language_manager');
    $definition->setClass('Drupal\language\ConfigurableLanguageManager')
      ->addArgument(new Reference('config.factory'))
      ->addArgument(new Reference('module_handler'))
      ->addArgument(new Reference('language.config_factory_override'))
      ->addArgument(new Reference('request_stack'));
    if ($default_language_values = $this->getDefaultLanguageValues()) {
      $container->setParameter('language.default_values', $default_language_values);
    }
  }
?>

This way of altering the service makes it hard for non-core modules to decorate the service, since the decorator cannot know the class of decorated service.

Proposed resolution

Instead of altering language manager service, language module could declare another public service, which will decorate language manager service.

Remaining tasks

- Create the new service (language.language_manager?) in language.services.yml
- Remove LanguageServiceProvider::alter() method
- Update the code of language module to use the new service
- Update the tests

User interface changes

No UI changes

API changes

New service language.language_manager, existing only when language module is enabled

Data model changes

No data model changes.

Release notes snippet

Language module exposes its own, extended language_manager service as language.language_manager

Issue fork drupal-3032067

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

valthebald created an issue. See original summary.

valthebald’s picture

Status: Active » Needs review
StatusFileSize
new5.4 KB

First take

Status: Needs review » Needs work

The last submitted patch, 2: 3030681.patch, failed testing. View results

valthebald’s picture

Status: Needs work » Needs review
StatusFileSize
new2.69 KB

Status: Needs review » Needs work

The last submitted patch, 4: 3032067-4.patch, failed testing. View results

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

siddhant.bhosale’s picture

Assigned: Unassigned » siddhant.bhosale
Yavor Petrov’s picture

I was strugguling with this for couple of hours and wasn't able to overwrite/decorate the LanguageServiceProvider to load my own LanguageManager in which I overwrite the getLanguages method. This is needed to filter some languages depending on the role and dynamic custom field of the user. So I created a new module starting with z (e.g. z_custom_overwritemodule) because the order of module execution is alphabetical. This way my custom ServiceProvider loads after the language's module one. Not the best solution but at least it works :)

valthebald’s picture

Status: Needs work » Needs review

Patch safely applies, moving to Needs review. I would argue that since this is kind of refactoring, no additional tests needed?

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

akalam made their first commit to this issue’s fork.

akalam’s picture

When trying to apply the patch on D8.9 project I got the following fatal error:

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Drupal\language\ConfigurableLanguageManager::__construct() must be an instance of Drupal\Core\Language\LanguageDefault, instance of Drupal\Core\Config\ConfigFactory given

After checking other branches (9.0.x, 9.1.x, 9.2.x and 9.3.x) I see the ConfigurableLanguageManager receives the default language in its constructor, so I think there is a missing argument in the service declaration.
Added a MR against 9.3.x branch with a new patch fix this issue. I can confirm the patch applies and is working in D8.9 sites.

admin@azhark.com’s picture

StatusFileSize
new85.86 KB

@akalam I checked on 9.3.x-dev, the 3032067-4.patch is working fine.
If possible add the changed patch which you created for D8.9

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative, +Needs tests, +Needs change record, +Needs upgrade path

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Tagging for tests to show the new service functionality

This will need an upgrade path for the backwards compatibility since it's changing existing services. Instead of changing them may need to pass in the new service and have a trigger_error.

Needs a change record to announce the new service and changes to existing one.

Thanks!

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

acbramley’s picture

This has been triaged as part of bug smash. Along with #21 this also needs a reroll and retarget of the MR to 11.x

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.