Call to a member function isTranslatable() on null in SqlContentEntityStorage

It this a blank page, as in pure white? If so, please read https://www.drupal.org/node/158043 and report back the error found. Was this not a problem on Drupal 8.3.x?

I found this happening after Drupal 8.4.2 as well, but not previously.

Here's a patch.

I also think I have found a work-around. You can find the field that doesn't have a definition by adding this code temporarily right above line 1183:

if (empty($definitions[$bundle][$field_name])) {
  dump([$bundle, $field_name]); die();
}

Then if you resave that field, the problem seems to go away. In my case, it was a "Text (plain)" field on a paragraph. Of course, I still think the patch is valid. Although $definitions[$bundle][$field_name] should never be empty, it clearly is for some Drupal sites and it would be better for the site not to give the WSOD if it's empty.

Rerolling patch for 8.5.0-rc1, also moving some of the logic out of the if statement so that it's more readable.

Those changes should not be necessary. When you look at the method implementation \Drupal\Core\Entity\Sql\SqlContentEntityStorage::loadFromDedicatedTables() you'll see that we retrieve the entries from the field table and read out the bundle from there. If $definitions[$bundle][$field_name] is not set then there is one possible error I could think of - for some reason you have an entry in the field table pointing to a bundle on which the field doesn't exist. How this happened is unclear to me.

Thanks for the feedback. Because the code didn't account for it before, it makes sense that the change shouldn't be necessary. Anyway, in my situation, something went off the rails, and it was necessary, so I created a patch. It looks like no one else has had the problem. I guess you can mark it as Closed (won't fix). If someone else encounters the issue and has more detail as to why it's happening, perhaps a better patch will come along.

I would suggest that you investigate the row being retrieved. You should not be needing the patch either. Closing the issue for now as without further information there is not much we can do. Feel free to re-open it if you want to dig in.

I'm responding to this closed issue because I had this exact problem too, and the patch brought my unresponsive back to life, so thanks for that. So I'm thinking this might be relevant after all?
My site was upgraded from Drupal 6 to 8, so maybe that plays into it?

We then need more information how this could be reproduced.

We are facing the same issue, i found some first clues:

We are migrating a site from D6 to D8 - the problem occurs after migrating translated versions of nodes. After digging a bit more in i found out, that migration of translations broke the node bundle in the node table.

I will investigate further, but at the moment i can say that the problem occurs if the type column in the node table differs from the bundle column in a field table. Example:

mysql> SELECT * FROM node where nid=39634;
+-------+-------+-----------------+--------------------------------------+----------+
| nid   | vid   | type            | uuid                                 | langcode |
+-------+-------+-----------------+--------------------------------------+----------+
| 39634 | 11228 | document_simple | 96f9e656-8476-4164-a204-169121be4941 | en       |
+-------+-------+-----------------+--------------------------------------+----------+
1 row in set (0.00 sec)

mysql> SELECT bundle FROM node__body where entity_id=39634;
+-------------+
| bundle      |
+-------------+
| publication |
| publication |
+-------------+
2 rows in set (0.00 sec)

@robotjox: Did you deal with translated content too? Can you execute this sql snippet in your drupal db to see if there is a mismatch too? It should return an empty result if everything is ok, otherwise it will return missmatched nodes.

SELECT * FROM node n LEFT JOIN node__body b ON (n.nid=b.entity_id) WHERE n.type!=b.bundle;

Also having this issue. This patch fixed for me

@akalam: Can you check if you get any results when you execute this sql query?

SELECT * FROM node n LEFT JOIN node__body b ON (n.nid=b.entity_id) WHERE n.type!=b.bundle;

Did you migrate contents from an old D6/D7 installation?

Having this issue in a D7->D8 migration and the patch fixed it.

@crash_springfield: Can you please executing my beforementioned statemenet in your database?

Thank you for mentioning that you migrated from 7 to 8. I have the theory that when using a node migration where the
destination.default_bundle is missing the bundle type is not saved correctly in D8. For me it looks like the default_bundle option did not exist in older migrate versions. So this may effect many migrations that have been started with older migrate months ago and are going to be finished now.

I have the same problem after importing content from D7 to D8.

I could not access the content Overview Page in D8, the patch solved this. But my main problem is that after I imported content from D7 to D8, I also lost a lot of content, which was previously created and has nothing to do with Import (the node type is not included in the import).

So imported content is fine, but unrelated nodes were removed during the import.

@Nebel54 What do you mean with: destination.default_bundle

All my imports have something like this:

process:
  type:
    plugin: default_value
    default_value: tattoo_appointment

@daveiano: You need to set the destination bundle as destination parameter, e.g.:

destination:
  plugin: entity:node
  default_bundle: tattoo_appointment

It helped in my case, but after studying #2700581, I'm not sure anymore if this was the fix to my problems. But you can give it a try. See also the Documentation which does not use the type parameter in the process section anymore.

@Nebel54: Ah ok I got you.

Ok I also looked into 2700581 but the issue is 2 years old? Dont know if the info from #40 is still relevant?

What is very strange: I did a second test:

First, I reimported a DB from before the first migration, so my lost content is back, the patch from #11 is still applied. Then I started a new import without changing anything in my migration sources or configs. Result: It works, no content was removed or changed...

I don't know if the issue was solved by the patch or if this is random behavior, but I will do a 3rd test to be sure without the patch.

I reimported all content without the patch applied - the same result, everything works.

No translation error and no missing content. But I suppose when doing the production import everything will crash...

I found out that my nodes were not disappeared during the import.

@Nebel54: Your SQL statement returned the nodes is was looking for.

They were attached to some of the imported content as translation, but I could not reproduce this again. Possibly some misconfiguration of the time of the import?

@daveiano: Thanks for your feedback! The problem disappeared for me when I set the target bundle in the process section and run the migration again. Did you also update your migration configuration, or did you leave the assignment in the process section?

@Nebel54: I changed it

from

process:
  type:
    plugin: default_value
    default_value: inquiry

to

destination:
  plugin: entity:node
  default_bundle: inquiry

Did I misunderstand something?

No, everything is fine :) It just was not clear to me if the problem disappeared in your case because of this change, or just by accident…

I think I found the problem for my special case:

We were importing Content from D7 to D8 in two steps: First, some content (let's say content type A and B), then a test phase and later a second import to import content type C and D. Between the imports other content got created (E).

I had the following in my migrations:

process:
  nid: nid

So I had the same nids in the old D7 site and the new D8 site. What I overlooked was that through the creation of Content E, some nids got occupied by new content. When then the second import was started, the nids were already taken and then overwritten with the new content, hence the mismatching.

I removed the nid: nid part and everything works fine.

I've rerolled patch #11 for branch 8.5.x.

Thanks for the patch, it helped avoid this error on my side.
Digging a little more, I haven't made any migration, but it looks like the field that Google Analytics Counter module adds during its installation is the culprit for me.

I updated the patch for 8.6.x branch

Thanks for the patch. It helped a lot. I got this error after uninstalling metatag submodule.

This also fixed the issue for me, also faced the same error in another module.

The patch in #33 worked for me. In my case, a D7 to D8 migration was working until I decided to change the machine name of the node bundle in D8. With the patch, the error went away.

The patch in #33 worked for me.

The patch in #33 worked for me as well.

Great to hear that the patch fixes the problem. Can you explain how you tested the patch. We can use it to create an automated test. In that way we can be sure that this fix does not accidentally unfixed.

In my case,

I have created a node and translated that node to some language(example: created node on "de" and translated to "en"). In my admin content translation settings enabled all fields and entities including paragraph entities. If I forgot any paragraph entities to enable in config translation and used that field in node, it throws isTranslatable() on null error.
Above patch is working fine in my case.

Thanks,
Revathi.B

The patch wasn't applying anymore, re run to 8.7.5.

#41 patch could not apply on 8.7.7 (with composer)

Attaching patch for 8.7.10

Note this occurred for me as an translated node was migrated to an existing untranslated node - not sure which field caused the error but patch corrected it.

Let the testbot run!

Back to needs work

Thanks to @Paul Rowell and all others contributing to this patch
The patch #43 works on D8.7.7 and D8.7.10 to give access to the content page ;-)
Still how can I locate the culprit node or paragraph that has translation issue ?

Added reroll of #43 in D8.6.x-dev.

Added reroll of #43 in D8.9.x-dev.

I have the same problem.
It started with 8.7, and was temporarily fixable by comment out this part of the file SqlContentEntityStorage.php lines 1281-1299.
When commented out, i was able to delete the last node, restore the code and remake the node.
It happens randomly. Sometimes 5 node's worked fine, and sometimes every node will break te site.

After update with drush ran into more problems. Restored from backup and updated manually to drupal 8.8. Same problem.

I run drupal 8.8 on lamp ubuntu vmware, the site is not migrated, but from scratch build. I did try to migrate my production site, but no luck. So i started from scratch. After 3 times run in errors i am not able to recover from, now this. I am manually transfer a 4500 page's site, and after three times starting all over it's getting annoying.

I am desperate. I walk from one error to the next error.

After update.php this is the error;
system module

Update #8804

Failed: Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '19' for key 'PRIMARY': INSERT INTO {path_alias} (id, revision_id, uuid, path, alias, langcode, status) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, - db_insert_placeholder_1399 ...... 429 [:db_insert_placeholder_1387] => 429 [:db_insert_placeholder_1388] => eff345de-5c4e-406c-abd9-eeae122568e9 [:db_insert_placeholder_1389] => /node/270 [:db_insert_placeholder_1390] => /canal_de_givors [:db_insert_placeholder_1391] => nl [:db_insert_placeholder_1392] => 1 [:db_insert_placeholder_1393] => 430 [:db_insert_placeholder_1394] => 430 [:db_insert_placeholder_1395] => c73781b7-3f94-4291-a460-9f308eb4613d [:db_insert_placeholder_1396] => /node/271 [:db_insert_placeholder_1397] => /canal_de_ille_et_rance [:db_insert_placeholder_1398] => nl [:db_insert_placeholder_1399] => 1 ) in Drupal\Core\Database\Connection->handleQueryException() (line 692 of /var/www/8binnenvaart/core/lib/Drupal/Core/Database/Connection.php).

@michelhensen: Sorry to hear of your troubles. Could you create a new issue for your problem and add the tag "8.8.0 update" to it. It should now be listed in: https://www.drupal.org/project/issues/search?issue_tags=8.8.0%20update. Unfortunately you are not alone with problems involving the updating to Drupal 8.8.0.

I will try. Thanks.

I will try. Thanks.

Patch applied cleanly

Hello, I was in huge trouble, losing precious days trying to locate the trouble.
This post help me on Drupal 8.8.2
The pach #50 for 8.9 works !
I did hesitate to apply as running D8.8 but it save not my day but my work that had been put in a nasty stand-by.
Thanks to all and @AkashkumarOSL.
UPDATE : With Drupal 8.8.4, the patch is still highly needed.

Applied the patch against 8.9beta2 and it fixed my problem. txx

This issue still needs tests.

We had the same error a few times on a website (Drupal 9.0.6). We assume the cause in connection with a cache clear when there is a too much traffic.

Why the $definitions is empty in that case, we could not evaluate yet.
But I am not sure how solid the patch #50 is. Because if $definitions is not present, we skip the complete language, which is then stored in the cache with the entity. This means, until the next cache clear we have an inconsistent state of the translation in the entity cache.

We are currently trying to determine the root cause.
If there is a missing definition we also remove the entity, to prevent it from being stored in the entity storage cache.

SqlContentEntityStorage::loadFromDedicatedTables()

// ...

if ((!isset($definitions[$bundle][$field_name]) || !$definitions[$bundle][$field_name] instanceof FieldConfigInterface)) {
  if (isset($values[$value_key])) {
    unset($values[$value_key]);
    \Drupal::logger('core')->warning('WRITE SOME LOGS...');
  }

  // Skip the language handling below as this definition is empty.
  continue;
}

if ($langcode == LanguageInterface::LANGCODE_DEFAULT || $definitions[$bundle][$field_name]->isTranslatable()) {
	// ...

#3195297: using convert_bundles module can expose db api bug

I just created a new patch for this.

Patch #50 worked for me!!

I just apply patch #50 and work well for me also solve this issue
Thank you @AkashKumar07

Confirming #50 fixes the issue for us, which we ran into in a Drupal 6 > 9 Migration. As there are several duplicates of this issue, coming from different use-cases (like e.g. #3195297: using convert_bundles module can expose db api bug or #3090206: Call to a member function isTranslatable() on null in NodeSearch, ...) we should decide how to proceed here and with which one. #3195297 has a much cleaner issue template and a similar patch. On the other hand, this has a lot more feedback.

Anyway, this indeed seems like a core bug which is quite common to run into, so it should be targeted.

Rerolled patch against 9.5x.

I was having issues applying the patch via composer, and I figured the issue was with the file path starting with core/. Rerolling to fix that.

Closed #3195297: using convert_bundles module can expose db api bug as a duplicate.

#70 applies to 9.5.3 (#71 not)

Tested #72 in Drupal 10.2.6 and 8.1.27,
it works but I had to set patchLevel to -p1 in composer.json , usually is -p2 for core patches.
It could be better to change lines, .../core/lib/... instead .../lib/...

(explanation patch level here: https://architecture.lullabot.com/adr/20220119-composer-patches/)

Create a MR based on #72.
Added patch of MR for use in composer.
Applies to 11.x and 10.3.x.