EntityFieldDeriver naive about field info, throws PHP warnings

I tried your patch on my local and works (I don't see any error), but I don't like it, I think the "continues" in code should not exist.

Specific warning is

Warning: reset() expects parameter 1 to be array, null given in Drupal\ctools_block\Plugin\Deriver\EntityFieldDeriver->getDerivativeDefinitions() (line 35 of /var/www/lightning8-distro/build/html/modules/contrib/ctools/modules/ctools_block/src/Plugin/Deriver/EntityFieldDeriver.php).

The error occurs only right after clearing cache, it seems to happen when a panel page is being displayed that contains a View Block of content nodes.
The $derivative_id field has value "comment:comment_body". What is odd is that comments are not enabled on this content type (or even this site), so not sure why it's going into the comment entity.

While this patch is a bandaid for the warnings, I'm not sure it's really how to handle this. Seems like a more fundamental issue with Views blocks and entities that have any field mapping.

Edited: You also get related warnings for different fields of various entities:
e.g.

Notice: Undefined index: user_picture in Drupal\ctools_block\Plugin\Deriver\EntityFieldDeriver->getDerivativeDefinitions() (line 26 of /var/www/lightning8-distro/build/html/modules/contrib/ctools/modules/ctools_block/src/Plugin/Deriver/EntityFieldDeriver.php).

I'm moving this back to needs work, because we haven't found out the root cause and as such do not know whether this is the correct fix. I agree with #5 and #6 in that this hides the warnings, but likely is no viable long-term solution.

I have been trying to dig through the entity field manager's code, but so far no look. Simply disabling its caches to check if perhaps they were simply stale did not help either. One thing that still needs to be checked is whether the entity.definitions.bundle_field_map item from state (key/value storage) as retrieved in EntityFieldManager::getFieldMap() might be stale.

You can also reproduce this error by:

1. Creating a custom entity
2. Include only a field storage in a modules config/install
3. Install module
4. Errors

We could have a field.storage, but no derivative. Like when you define a field storage, and wait till a bundle is created to add the field.

That is the same fix as before. Multiple people expressed their concern at fixing it like this, because we don't know what the cause is and if this fix has side-effects.

When you say derivative, do you mean a field (instance) on an entity bundle?

Yes. Sorry about that. I meant field instance.
Edit for posterity: The code is looking for a derivative.

I read #8 and the code again and now I understand why the code fails. I'll dig into this again after the weekend. Thanks for sharing the steps to reproduce the problem!

I'm able to reproduce this in the same way as #8/#10 explains, ie. having a field storage without any field instances using it. Based on that, I think #2 is probably a fine solution?

Or, we could try to fix this in core by having EntityManagerInterface::getFieldMap() return fields without instances? There's nothing in it's documentation that would indicate that it wouldn't return fields without instances. But that would be a change, in behavior, so maybe we just document it's current return value?

I think that #8 accurately explains how this bug is caused by a wrong assumption. EntityFieldDeriver expects to map field data to field storage data 1:1, but fails, because fields do not always have to exist for field storages. Based on my knowledge of Field API I can say that this is a perfectly acceptable situation that EntityFieldDeriver assumed would never happen.

Based on that conclusion, I can say that the original patch is a valid fix in terms of behavior, albeit perhaps not the one that produces the cleanest code.

This takes @TravisCarden's original approach from #2, but adds documentation and changes a variable name so the situation is more clear.

Always great if your IDE marks unused variables accordingly.

#16 works good for me. The explanatory comment in the patch looks good as well. RTBC +1

I was getting this error when running drush cr and #16 fixed it for me.

I was geting this error and #16 fixed it for me.

I like the patch in #16. It documents the problem being solved effectively and fixes the messages.

RTBC +1!

Yah #16 is much better. We'll need to readdress this later, but for now... Committed.

Woohoo! Thanks!