Hey Damien,

Just somewhat reopen first part of #1291422: Add support for the Title module. It's broken regardless access control as you supposed. So what happens with i18n:

1. English node
2. Spanish node
3. Referred node (lang neutral).

You can perfectly enter (3) in Eng. node. And the field auto syncs fine to Spanish. Ref (autocomplete) field looks like: Bachata Basic Dance Step (279).

But when you try to edit->save Spanish you'd get ann error: The referenced entity (node: 279) is invalid.

And to polish it all, nothing happens if you try to enter the same node manually. Autocomplete picks nothing. And no errors in the log.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

colan’s picture

Title: i18n issues » The referenced entity is invalid (for translations)
Issue tags: +i18n

Fixing title & adding tag.

Still investigating, but it only happens from the non-default language interface. So if English is the default language, and you're looking at the English interface, when you edit the French version (for example) and save, it's fine. The problem occurs when you're editing the French translation through the French interface, and then try to save it.

amitaibu’s picture

Can you provide a simple step by step on how to reproduce (you can even attach a db dump with the initial setup).

colan’s picture

  1. Set up an English site.
  2. Add French as an additional language.
  3. Enable the Entity translation module. (Field translation is used instead of node translation.)
  4. Create a content type with a non-translatable Entity reference field.
  5. Create a node "A".
  6. Create an English node "B" of the content type created earlier, populating the Entity reference field with "A" as the target.
  7. Create a French translation for "B".
  8. Attempt to save it.
  9. On save, you'll notice that the error is produced even though it saves without problems on the English side.

What I've discovered so far is that if the following is commented out, it works fine:


diff --git a/drupal/sites/all/modules/entityreference/handler/base.inc b/drupal/sites/all/modules/entityreference/handler/base.inc
index ddb9d30..bfd7896 100644
--- a/drupal/sites/all/modules/entityreference/handler/base.inc
+++ b/drupal/sites/all/modules/entityreference/handler/base.inc
@@ -182,7 +182,7 @@ class EntityReferenceHandler_base implements EntityReferenceHandler {
     }
 
     // Add a generic entity access tag to the query.
-    $query->addTag($this->field['settings']['target_type'] . '_access');
+//    $query->addTag($this->field['settings']['target_type'] . '_access');
     $query->addTag('entityreference');
     $query->addMetaData('field', $this->field);
 

So it appears to be a problem with node access permissions. I haven't got any further than that at this point.

colan’s picture

Another thing I just discovered: It doesn't matter if it's a translation being added/edited. I just tried creating new content from the French interface (choosing any language for the content), and the same thing happened. It didn't accept anything. Using the same initial characters, the auto-complete field didn't return any results from the French (non-default) interface of the create form while it did from the English (default) side.

colan’s picture

Status: Active » Needs review
FileSize
1.58 KB

It appears as though this security check is unnecessary in an EntityFieldQuery. According to the API, "[n]ode access control is performed by the SQL storage engine but other storage engines might not do this." This is further supported by Damien's comment over at How to bypass node_access when using EntityFieldQuery? For details on how this came to be, see the discussion and patch for #860180: Entity listing and loading does not allow for node access.

I've therefore removed it under these conditions. The additional check appears to mess things up.

Status: Needs review » Needs work

The last submitted patch, skip_node_access_check_if_already_done-1332262-5.patch, failed testing.

colan’s picture

Version: 7.x-1.0-beta1 » 7.x-1.x-dev
Status: Needs work » Needs review

I think that should have been on the dev branch, sorry.

colan’s picture

Issue tags: -i18n

Status: Needs review » Needs work
Issue tags: +i18n

The last submitted patch, skip_node_access_check_if_already_done-1332262-5.patch, failed testing.

renat’s picture

Just in case some of you do not know, there were a tip posted in original "Add support for the Title module" issue. It completely solves problem mentioned in topic-starting message here. Though, in case proposed patch can improve module architecture, it would be great to finish it.

colan’s picture

Status: Needs work » Fixed

I was about to re-roll this for the latest code in the dev branch, but I can no longer reproduce it. It seems as though it was fixed though other means. Please reopen if I'm missing something.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

donquixote’s picture

Status: Closed (fixed) » Active

I experienced this issue myself, on a (single-value) entityreference on a taxonomy term referencing a user.
I managed to fix it by re-saving the field configuration.

It seems that sometimes parts of the field configuration are lost.
It reminds me of this one, #1825256-39: Does not work for Organic groups og_group_ref field

lorenz’s picture

Issue summary: View changes

I had the same problem and the solution was to enable translations for the entity reference field. This was not the case as I recently upgraded from content translation to entity translation.

If you are experiencing the same problem, try this:
- go to the field settings of the entity reference field
- click "enable translations" link at the bottom of the edit form

MustangGB’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.