Call to a member function getThirdPartySetting() on null in ContentTranslationManager

Let's also document on \Drupal\content_translation\ContentTranslationManager::loadContentLanguageSettings that the method can actually return NULL;

I experienced the same issue and applied this patch. But it's introduced a new error:

exception 'RuntimeException' with message 'Unable to determine class for field type '' found in the 'field.storage.' configuration' in /web/core/modules/field/src/FieldStorageConfigStorage.php:157

So I think the provided patch isn't the right approach.

The patch in #2 worked for me.

@dawehner, good idea to document this.

The patch in #2 worked for me.

#2 works for me to in 8.3.x

Thanks,
using Drupal 8.4.2 and drush config-import stopped at the end with this content_translation error.

Patch from #2 solved this error for me, thanks!

I had the same error message during cim with PHP 7.1 and it turned out that with PHP 7.0 it works without any errors, so in our case this workaround was the solution.

Patch works for me!

Updated patch based on #3. Would be nice with a test as well?

Using patch 2868294-12.patch with the latest 8.5.RC1
Error: Call to a member function getThirdPartySetting() on null in Drupal\content_translation\ContentTranslationManager->getBundleTranslationSettings() (line 122 of [PROJECT]/web/core/modules/content_translation/src/ContentTranslationManager.php).

Applying the same trick !is_null($config) to the getBundleTranslationSettings did the trick.

Hi everyone.

Patch 2 works for us too. Is there any update on this please? Thanks in advance.

@iainp999 Why are you using patch nr2 ? It's an incomplete patch. See comment #3.

Please test te latest patch and/or mention which version of Drupal + Module you are using. Please explain more than I used #X and it works... we need to know the circumstances of your environment. Thank you.

We're on 8.4.6 - there's no alternative on this thread yet?

Looks good and fixes the fatal error.

We're on 8.4.6 - there's no alternative on this thread yet?

Probably it could be back ported to 8.5.x, not sure about 8.4.x though.

+++ b/core/modules/content_translation/src/ContentTranslationManager.php
@@ -95,7 +95,7 @@ public function isEnabled($entity_type_id, $bundle = NULL) {
+        if (!is_null($config) && $config->getThirdPartySetting('content_translation', 'enabled', FALSE)) {

@@ -119,7 +119,9 @@ public function setBundleTranslationSettings($entity_type_id, $bundle, array $se
+    if (!is_null($config)) {

The !is_null() is not necessary. It's fine to just check if ($config)

Changes done as per comment #20 & also added an interdiff.

@yogesh-pawar thank you. I think you still have a call to is_null() in your patch in 22 though.

if (!is_null($config) && $config->getThirdPartySetting('content_translation', 'enabled', FALSE)) {

thanks.

How about the attached? Thank you.

Thanks @iainp99. Just realised it'd be possible to get NULL all instances of loadContentLanguageSettings call. How about this?

Thanks for the quick turnaround. Didn't test the issue, but re-marking RTBC per #19.

Ahem.

Here's a backport to 8.4.x for #25 in case someone needs it :)

thanks @manuel-garcia!

In order to commit a bug fix we need an automated to test to prove that we've fixed the bug and ensure that we don't break it again in the future. For more information about writing tests in Drupal 8 see the following links:

1. https://www.drupal.org/docs/8/testing
2. https://api.drupal.org/api/drupal/core%21core.api.php/group/testing/8.5.x

Also we need some understand of how we get to the point where this is null and why and whether the fix is correct.

Setting it to needs review to test.

Also we need some understand of how we get to the point where this is null

We might need a functional test for this.

@vijaycs85 I think you've got a typo in a method name:

public function tstSetBundleTranslationSettings() {

Thanks @iainp999. Here is an update.

Sorry, another silly mistake on #35

Fixing another unintended failure.

2868294-41.patch Updated to 8.5.x core.

Attaching for 8.5.3 specific patch.

Thanks @KittenDestroyer. I believe this needs to be addressed first on 8.6.x so switching the issue's version back to that :)

For clarity, the patch to continue work on/review is still #41.

Is a missing config a real issue that this solution just hides?

Patch works and looks good. Since I have a patch in this issue, leaving to others to RTBC.

Reviewing the patch in #41, I noticed that the comments and naming of functions and dataproviders seems to be taken from somewhere else (probably copy-pasted). Small nit though.

Removing the needs tests tag.

1. +++ b/core/modules/content_translation/tests/src/Kernel/ContentTranslationManagerTest.php
   @@ -0,0 +1,96 @@
   +  protected $strictConfigSchema = FALSE;
   

   Why are we disabling strict config schema checking here? We probably shouldn't do that if we can help it.

2. +++ b/core/modules/content_translation/tests/src/Kernel/ContentTranslationManagerTest.php
   @@ -0,0 +1,96 @@
   +   * Modules to enable.
   +   *
   +   * @var array
   

   Can be {@inheritdoc}

This fixes my own remarks.

I think #2599228: Programmatically created translatable content type returns SQL error on content creation is related here. The lates patch there (https://www.drupal.org/files/issues/2018-10-06/2599228-74.patch) is also solving this error.

Since the other patch has also already been RTBC before, we should probably close this. Not sure though.

I encountered this error on Drupal 8.6. I tried #74 in #2599228: Programmatically created translatable content type returns SQL error on content creation and it didn't help. But #51 in this issue worked great, so it seems like there's a gap between the two approaches. Not sure if that's specific to 8.6 or what.

I'm afraid the patch introduces another bug.
I have an install script that
- install a brand new Drupal site
- import the configuration
- run migrations to populate the database

I started to get the "Call to a member function getThirdPartySetting() on null in ContentTranslationManager" at the end of the import configuration step, so I tried the #51 patch. It removed the error message, but now I run into this problem: https://www.drupal.org/project/drupal/issues/2599228.

With the #51 patch, the column content_translation_source in table node_field_data is not created during the install / import config process. If I remove the patch, the column is created like it should be.

I can confirm that patch from #51 creates an issue with missing content_translation_source column. Patch from #2599228-105: Programmatically created translatable content type returns SQL error on content creation does not fix this issue on it's own.

Seems like the in order to fix the issue both patches are required. One from here and one from #2599228-105: Programmatically created translatable content type returns SQL error on content creation. The problem is that they cannot be applied together. I think those two issues should be combined into a single one.

He's a patch that can be applied after #2599228-105: Programmatically created translatable content type returns SQL error on content creation.

So, should those 2 issues be combined? Or just wait until the other one is committed.

Regarding questions in #30 and #46 that we are fixing not the real issue here, as config should not be null. The easiest way to reproduce this is to create a block content block and export it to configuration. As you might know custom blocks are not exported "correctly", see #2756331: Custom blocks cannot be properly exported and imported. Then try to install site using config_installer. Boom.

Added test manually because off issue status :)

Combined #2599228-105: Programmatically created translatable content type returns SQL error on content creation with #2868294-59: Call to a member function getThirdPartySetting() on null in ContentTranslationManager against 8.6.x

[##2599228] has been committed so we can now concentrate on this issue without having to combine patches.

I couldn't get the patch in #59 tested so here's a reroll of #59 against 8.8.

Would be great to have an updated issue summary update, when this happens exactly and what we are doing to fix it.

All upgraded to the 8.7.0 core just now and this patch failed https://www.drupal.org/files/issues/2018-09-26/2868294-51.patch What are you all using for 8.7.0?

Hello @neelaj82,
I have this same issue. Did you find how to fix it ? Thank you !

patch 2868294_64.patch from nr 64 should work ?

Thanks ! For the current version of 8.7.x, I tested the patch #64 and it works. The fail triggered during test seems to be related to the new file ContentTranslationManagerTest.php and it doesn't impact the issue itself.

Had kind of the same issue after reusing a database where the system.menu.devel config wasn't correctly imported, but I missed that part so I went on with the idea that everything was fine. But when I uninstalled the module webprofiler, the message was the same as in the description of this issue.

After some debugging, I could trace the issue back to system.menu.devel in the config table. The stored configuration was missing an ID and some other data, only the dependencies array was available.

The problem in my case was, when https://git.drupalcode.org/project/drupal/-/blob/9.3.x/core/lib/Drupal/C... (\Drupal\Core\Config\Entity\ConfigEntityStorage::doLoadMultiple) is searching for the 'id' ($id = $config->get($this->idKey);) in the config record, it is missing. Because of the missing ID in the stored config, the key for processing configuration entity bundles array will be empty, and result in a empty key with a config entity object that isn't usable.

The patch just hides the invalid config in the database, I think it would be better to be aware of the problem and/or exclude the invalid config earlier on in the code at ConfigEntityStorage::doLoadMultiple().

After I removed the config entry and run config import with Drush, the issue was gone. I tried to recreate the situation, but wasn't able to.

Site setup: Drupal 8.9.19 with Configuration Split (1.7) for Devel & Webprofiler

Rerolled patch against drupal-9.5.x-dev

Fixed failed commands on #78
Attached interdiff

Fixed failed tests of patch #81.

Added patch against #84 in Drupal 10.1.x

Thanks @shubham-chandra for the patch #87.
It works well on Drupal Core 9.4.8 with PHP8.0 & Mysql 5.7.

Patch #87 doesn't fix anything, it instead removes the tests that are failing, but those tests are there for a reason. The correct approach would be to get those tests passing, not removing them. Work should continue from an earlier patch that includes ContentManagerTranslationTest

Patch of !MR8986 (works on 11.0 and 10.3, 10.2)

Tests are working now, but someone should have a look at what those test values should do...

patch for MR

I was looking a bit more into the test that is failing (data index 3). The test data uses a non existing bundle id. What happens then is loadContentLanguageSettings initially cannot find the config and then creates a new one for the non existing bundle.

So either a couple of things should happen:
- the test data is incorrect and tries to test a situation that can never happen, being a non existing bundle id and the hasexception flag set to false or
- loadContentLanguageSettings should not create a config for a non existing bundle, and should return null. So loadContentLanguageSettings should check if the entity_id and bundle actually exist?