Notice: Undefined index: #entity_type in rdf_preprocess_field()

I don't know why this index is missing but this change in line 551 of rdf.module should remove the the notice:
Change

$mapping = rdf_mapping_load($element['#entity_type'], $element['#bundle']);

into

  if(!empty($element['#entity_type'])){
    $mapping = rdf_mapping_load($element['#entity_type'], $element['#bundle']);
  }

Attached the patch file

This issue is still present with Drupal 7.39

Confirmed, this is still in Drupal Core 7.51
Rerolled against git.

Following issue https://www.drupal.org/node/2676826

Hi,

I can confirm that this patch is fixing the issue.

Hello,

I had to work an issue that generates this message. It appeared at the end that it was a problem in the custom code.
An component was added to a content display like it is a field in order to be rendered with the field theme. All "field" variable items were correctly defined; except the entity type.
Once the array item "#entity_type" has been added, the message disappeared.

I checked the issue of the description. The message was appearing on a site that uses the "node registration" module.
They fixed the issue in their code too, see #2389375: Registration Rendering reports multile "Undefined index: #entity_type" notices.
The problem was in "fake" fields defined without setting the entity type and the bundle that we expect set for a field.

Based on these observations, I challenged the issues #2676826: Undefined index: #entity_type in rdf_preprocess_field() in order to see if the origin of the issuer there was not the same as above.
It appears the Project issue tracking module also produces 3 "fake" fields where the "#entity_type" item was not set, which produces the same error message.
I made a patch that set the '#entity_type" item that fixes this.
I submitted it in the issue. I meet an issue with the composer phase of the automated tests; that is why it is in the "needs work" state but I tested it on different environments on my side and it actually fixes this issue.

These elements combined to what I observed in the Field API makes me say that we should not use the patch because it just hides the error message but not the root cause of the problem; which is a malformed field definition.

Indeed, when you check functions like "field_view_field", "field_attach_prepare_view" or "template_preprocess_field", the entity type is a mandatory element in a field definition because it is a mandatory parameter in the field API or used without testing if it is set or not.
Then, from the API point of view, IMO, this data must be considered as always there and if this message appears that means a field (true or fake) is incorrectly defined somewhere in the code and it must be fixed there.
That will allows us to keep it the code light without multiplying the existence control everywhere on elements considered as mandatory.

I pass the issue in needs work to allow evaluating this point of view and deciding if the patch should eventually be committed or not.

Hello,

Thanks for the feedback, please let us know the outcome of your investigations, we'll take the decision after that.

Hi.

I achieved my investigations.

I can say that all problematic cases I met are related to "fake/pseudo" fields that do not have the "#entity_type" item defined.
In all cases, the proposed fix to add this item in the "fake" field array where it was missing, has been accepted.

I am still convinced the patch is not needed for the reasons I mentioned in my previous comment.