Call to a member function set Weight() on null in Drupal\language\Configurable LanguageManager->updateLockedLanguageWeights()

Getting the same error on Drupal 8.6.2 when adding a new language (Dutch) through the configuration menu.

The website encountered an unexpected error. Please try again later.
Error: Call to a member function setWeight() on null in Drupal\language\ConfigurableLanguageManager->updateLockedLanguageWeights() (line 357 of core/modules/language/src/ConfigurableLanguageManager.php).
Drupal\language\ConfigurableLanguageManager->updateLockedLanguageWeights() (Line: 133)
Drupal\language\Entity\ConfigurableLanguage->postSave(Object, ) (Line: 506)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, ) (Line: 432)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 390)
Drupal\Core\Entity\Entity->save() (Line: 632)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 296)
Drupal\Core\Entity\EntityForm->save(Array, Object) (Line: 87)
Drupal\language\Form\LanguageAddForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('language_admin_add_form', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('language_admin_add_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 665)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Afterwards, the lagnuage is imported with 0 translations. If I would try to set the new language as default, it get a similar error and errors at the top of every configuration page until I set the default to English again.

I have the same error after adding a new language (Dutch) in the configuration menu's

The website encountered an unexpected error. Please try again later.
Error: Call to a member function setWeight() on null in Drupal\language\ConfigurableLanguageManager->updateLockedLanguageWeights() (line 357 of core/modules/language/src/ConfigurableLanguageManager.php).
Drupal\language\ConfigurableLanguageManager->updateLockedLanguageWeights() (Line: 133)
Drupal\language\Entity\ConfigurableLanguage->postSave(Object, ) (Line: 506)
Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, ) (Line: 432)
Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage->save(Object) (Line: 390)
Drupal\Core\Entity\Entity->save() (Line: 632)
Drupal\Core\Config\Entity\ConfigEntityBase->save() (Line: 296)
Drupal\Core\Entity\EntityForm->save(Array, Object) (Line: 87)
Drupal\language\Form\LanguageAddForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 589)
Drupal\Core\Form\FormBuilder->processForm('language_admin_add_form', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('language_admin_add_form', Object) (Line: 93)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 665)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

After this, the language is imported with 0 translations.
When I set this as default language, it gives more errors on every configuration page until I set English as the default again.

I got the same issue.
Upgraded the core and such, same issue as with adding Dutch.
Seems like a bug in the latest Drupal ?

Hi Guys,

I have tested the Dutch language installation on Drupal 8 and set this as default language, it works fine.

Can you elaborate little bit more, so I understand more.

Made some screenshots, which shows the error and what I exactly do:

Hi Power2All,

I have tested same with Drupal Version 8.5.1. Its working fine.

You may review here.

https://dmydh.ply.st/

UserName: admin
Password :admin

Hi,

I have tested the same with Dutch and Hindi language on Drupal 8.5.5 and set this as both one by one as default language, it works fine.
please update your core

An updated core did indeed fix this. Thanks to however fixed the core ;-)

Hi,

I'm experiencing this same issue on 8.6.10. Does anyone know what the fix for this was?

Thanks

I am also facing same issue but when i am trying to add custom language i.e. en-bg

I came across this issue on Drupal 8.7.8, so providing a patch but I'm not able to change the status from Closed to Needs Review...

Opening this back up, since it should not have been marked 'Fixed' to begin with, it probably should have been marked 'Outdated' or 'Cannot reproduce' if anything.

We still need steps to reproduce this and an automated test to prove that this is a bug and a solution like #14 isn't just hiding broken config.

For my "steps to reproduce" - it seems to be that using the current Amazeelabs/silverback "composer" dependency and then running silverback setup, then head to the Languages page to add a new language, then add a language and you'll get the error.

Steps to reproduce:

1. Run the command:

   composer create-project drupal-composer/drupal-project:8.x-dev my-project --no-interaction

2. Add silverback with the following:
   

   cd my-project
   composer require amazeelabs/silverback
   ./vendor/bin/silverback init
   composer install
   yarn

3. Go to the languages page, you should see no languages listed on the page
4. Add new language, such as French
5. Save and you should get the error

The patch of #14 works for us. (D8.5.15)

Add the patch for Drupal 8.7.x core version.

Add the patch for Drupal 8.8.x core version.

Getting this error with zxx and und language codes, but not entirely sure why, since this does not seem to appear always. Given that, it could be that patch for this could be somewhat harmful and instead the configuration needs to be fixed.

In my case it seems that this error appeared when I tried to run drush si --existing-config -y and the configuration was missing configuration that should have been delivered by language module. Could you confirm whether that is the case for you as well?

Hide the old patch.

I am receiving the same error on core version 8.8.5. The language is added however without any issues.

I can confirm that patch #20 is working for me. Core version 8.8.5

Ran into this on 9.1.x while trying to save the demo_umami profile config, 'language.entity.es'. This was while developing a Kernel migration test for the json_api source plugin.

    $entity_type_manager->getStorage('configurable_language')
      ->create($source->read('language.entity.es'))
      ->save();

Since that fails, just creating the language works.

    $entity_type_manager->getStorage('configurable_language')
      ->create([
        'id' => 'es',
      ])->save();

Error persists on Drupal 9.1, when submitting admin form to enable Spanish.
This is a site that was set up from configuration. The patch #20 works for me.

Error persists on 9.2.6. I was experiencing it on /admin/config/regional/language after adding Arabic to the site. Patch #20 worked. It removes the fatal error.

Just came across the same issue when writing a kernel test.

For #3002532-21: Call to a member function set Weight() on null in Drupal\language\Configurable LanguageManager->updateLockedLanguageWeights()/#3002532-22: Call to a member function set Weight() on null in Drupal\language\Configurable LanguageManager->updateLockedLanguageWeights() and #3002532-27: Call to a member function set Weight() on null in Drupal\language\Configurable LanguageManager->updateLockedLanguageWeights(), it seems the issue is that non-locked languages do not depend on locked languages.
So we cannot guarantee that locked languages exists just by installing the config since the dependency is not set.
Does the dependency should be clearly defined for each config? If yes, then we should also make sure to add the dependencies when generating the config in addition of the current patch no?

Seeing this issue on a 9.4.7

[error] Call to a member function setWeight() on null

This appears both when I am using the UI and when attempting to add programmatically like:

In code:

  ConfigurableLanguage::create(['id' => 'zer', 'label' => 'zero', 'weight' => -1])->save();

And in drush:

 drush ev "\Drupal\language\Entity\ConfigurableLanguage::create(['id' => 'one', 'label' => 'drushtest'])->save();"

 drush ev "\Drupal\language\Entity\ConfigurableLanguage::create(['id' => 'two', 'label' => 'drushtest2', 'weight' => '1'])->save();"

This also happens when I use the UI to delete a custom language, returning this error:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function setWeight() on null in Drupal\language\ConfigurableLanguageManager->updateLockedLanguageWeights() (line 369 of core/modules/language/src/ConfigurableLanguageManager.php).

Patch 20 worked for me.

I have the same question too. and patch#20 worked for me too

in the file :core/modules/language/src/ConfigurableLanguageManager.php

change the origin updateLockedLanguageWeights function

// public function updateLockedLanguageWeights() {
  //   // Get the weight of the last configurable language.
  //   $configurable_languages = $this->getLanguages(LanguageInterface::STATE_CONFIGURABLE);
  //   $max_weight = end($configurable_languages)->getWeight();

  //   $locked_languages = $this->getLanguages(LanguageInterface::STATE_LOCKED);
  //   // Update locked language weights to maintain the existing order, if
  //   // necessary.
  //   if (reset($locked_languages)->getWeight() <= $max_weight) {
  //     foreach ($locked_languages as $language) {
  //       // Update system languages weight.
  //       $max_weight++;
  //       ConfigurableLanguage::load($language->getId())
  //         ->setWeight($max_weight)
  //         ->save();
  //     }
  //   }
  // }

into this function:

public function updateLockedLanguageWeights() {
  foreach ($locked_languages as $language) {
    // Update system languages weight.
    $max_weight++;
      $configurable_language = ConfigurableLanguage::load($language->getId());
      if ($configurable_language) {
        $configurable_language->setWeight($max_weight)->save();
      }
  }
}

Addressed Comment #37. Needs Review.

Fixed failed commands on #39
Attached patch against Drupal 10.1.x

I have fix CS error. Please review it

#39 worked for me on 9.5.
Thanks

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.

#41 has some erros
And this was previously tagged for steps to reproduce and tests which still need to happen.

Thanks.

Try TO Fix the #41 custom CMD Failed Patch.

The last 3 patches did not work for me on Drupal 10.1, unfortunately. I created a merge request adding simple validation before setting weights, which I belatedly realized is the same as the patch in #20.

The larger issue seems to be that locked languages (and the default language in my case) cannot be loaded as ConfigurableLanguage entities.

Since the last patches did not work for me on Drupal 10.1.x.
Thus I have created a new patch and its is working fine.

Kindly review the patch.

I've a patch from this issue on few projects, however I believe the root cause is same as @Dropa mentioned on #21 & #22. Tried to reproduce the issue with steps from #36, but no luck. So I'd vote for closing this as outdated/cannot reproduce (on clean install). The missing configuration should be rather easy to find with https://www.drupal.org/project/config_inspector now that #3426309: Add config validation for weights (blocks, filters, etc. all use weights) has landed on 10.3.x

I had this issue on Drupal 11.0.4 and it was because there was no language.entity.en config entity. There were such entities for various other languages, just not en. I have no idea how that happened.

Just because it might mask an underlying issue is no reason not to make the updateLockedLanguageWeights method more bulletproof.

I've attached my attempt to do that based on D11 dev of Oct 18, 2024.

I ran into this today. It couldn't load 'und' and 'xxx' in Drupal 10.

I think we shouldn't increment if we can't load the language:

foreach ($locked_languages as $language) {
        $configurable_language = ConfigurableLanguage::load($language->getId());
        if (!$configurable_language instanceof ConfigurableLanguage) {
          continue;
        }
        // Update system languages weight.
        $max_weight++;
        $configurable_language
          ->setWeight($max_weight)
          ->save();
      }

Tags for steps to reproduce, issue summary update, and test still applyl

Updated the issue summary with Steps to reproduced.

Also tested the MR !10640 - and confirm it works

I hit this issue testing Drupal CMS. Patching with #56 resolved the problem for me. Adding the Drupal CMS dependency tag on this issue since it seems to block the ability to install new languages in Drupal CMS.

Patch #56 works for D11.1.2

Patch #56 works on D11.1.3

Patch #56 works on 10.4.2

This bug can prevent recipes from shipping translations without adding the following workaround to language entities:

dependencies:
  config:
    - language.entity.und
    - language.entity.zxx

Tagging, therefore, as part of the Recipes Initiative.

Question about the proposed fix here:

• Why is there a need to return the number of languages changed? That seems superfluous and is adding complexity to the patch.
• Could we not just fix this by using the null-safe operator when trying to load the configurable language that may or may not exist? Surely that would get us past this problem elegantly, and would fix the flawed assumption which is causing the bug (namely, that the Language module is assuming that all of its config actually exists, which is not and never has been a safe assumption).

It isn't really necessary to return the number of rows processed but it's only using three lines. I can take those out if that causes problems. Or I can add a return type hint.

The original method is making several assumptions that might result in errors, I tried to resolve those. There are such assumptions before the ConfigurableLanguage::load line so I don't think just fixing that is going to solve it. I'm open to trying to make it even more bulletproof, such as by checking that things are arrays.

I had the fatal error on a project with Drupal 11.4.4. I installed the changes from the latest MR update and the error was gone.

I faced the same issue