Fatal error on cache rebuild: getTargetEntityTypeId() on null

Yeah my first question would be why was it NULL in the first place. I'll see if I can reproduce on a new site install... with views_natural_sort_test installed. If not we need to see what field type causes that.

It's very possible that I'm in the middle of somethijng there too like trying to get text fields to work :p

Been a while so I can't say for sure

I hit this error as well. The patch resolved the error, and I can see that the problematic field was from the video entity: Notice: Undefined index: field_media_oembed_video in Drupal\views_natural_sort\ViewsNaturalSortService->getSupportedEntityProperties() (line 124 of modules/contrib/views_natural_sort/src/ViewsNaturalSortService.php).

I'll give that a shot.

In support of #4, I did some debugging and noticed $fieldConfig is null for the field field_media_oembed_video.

The problem is the field definitions for the entity type doesn't include that field. The field is attached to the remote_video bundle of the media entity type.

The field definitions are obtained here:

$fieldConfigs = $this->entityFieldManager->getBaseFieldDefinitions($entity_type , reset($field_info['bundles']));

See getBaseFieldDefinitions() documentation:

Gets the base field definitions for a content entity type.

Only fields that are not specific to a given bundle or set of bundles are returned. This excludes configurable fields, as they are always attached to a specific bundle.

While the field field_media_oembed_video is specific to the bundle, it may be considered a "configurable field", but I'm not sure. It can't be deleted so I'm not sure if that means it is configurable.

Hi, I'm seeing the other error now after applying the patch.

Notice: Undefined index: field_custom in Drupal\views_natural_sort\ViewsNaturalSortService->getSupportedEntityProperties() 

It's one of my custom field from my node entity and it's happening whenever I try to save the one of the views or try to install site from config on our CI environment.

After looking into the codebase, what I don't get is it's trying to grab the field config of all the entity fields from the values returned by the method "getBaseFieldDefinitions" and which won't return the field config for custom fields like what comment #6 pointed out.

I created a patch that replace the method "getBaseFieldDefinitions" with "getFieldDefinitions" because the method "getFieldDefinitions" would return config for all fields including the custom fields. Also, the original method "getBaseFieldDefinitions" would only take one argument but it's currently passing two arguments, so I assumed "getFieldDefinitions" is the one that should be called here.

I also updated the logic a little bit based on the first patch, so it looks clearer in the patch file. The previous logic was just wrapping all the code inside an if statement but it created a lot of file diffs.

Okay, it looks like we still need to use the "getBaseFieldDefinitions" method for entity types that don't have any bundles, for example, comment.

Here's the updated patch.

This worked out with my testing as well. making this as fix for the next release.