Entity Translation support

Have you tried the title module?

I'm not sure if this solves the issue, but it would be nice if you could test that.

We uses Entity Translation and the Title module. The search is done using the title in the source language, but the display uses the replacement field.

The current search is done using EntityFieldQuery which is great, except that it does not support OR condition. Depending on the configuration, for the same entity type you could have some bundles using the replacement title field and some using the title property.

The attached patch support searching based on the title replacement field. Because EntityFieldQuery does not support OR condition, two queries are sued when both property and field searches are need. When the search is restricted to bundles with only title replacement field or title property, only one search is used.

Also, the code in LinkitSearchPluginEntity::createPath generate a link using the entity language property as prefix. An entity translated with Entity Translation does not have a language. But all translations of the same entity does share the same path, so a link in any language should work.

The attached patch (applied before the one in #5) add a different language handling for entities translated using Entity Translation and uses the current interface language for the link. Ideally, the language should be the one of the edited translate (en/node/42/edit/fr let you edit the french translation of the node with an English interface) but this would require a major re-factor of the auto-complete field.

Hi, I was unable to apply the patch in #5. I am using the wxt distribution of drupal that uses linkit 7.x-3.1+15-dev with entity translation and title module.

patching file `entity.class.php'
Hunk #1 FAILED at 193.
Hunk #2 succeeded at 298 (offset 17 lines).
1 out of 2 hunks FAILED -- saving rejects to entity.class.php.rej

I have created a new patch, building on the patch in comment #6, but using a different approach to expand the search to fields replacing the entity label (using "title" module).

Works fine for node entities here. It should also work for other entity types which have their label property replaced by a field - but I didn't test that for now.

I like the approach for patch in #8.

I have been testing this patch in place of our own customizations to Linkit to support ET. Our logic however didn't include fallback behavior which made this patch more appealing.

Additionally our Behat tests still pass and based on personal tests also looks good.

Hope it is ok if push this to RTBC.

I couldn't get this to work. I applied the patch manually to the latest dev-version, because it failed. Here is the patch to latest dev.

When I go to add a node in default language (Finnish) I get the results when adding a link with a wysiwyg button, but when adding a node in English, which is not the default language, it doesn't find anything. And I have translated the same content which appears in Finnish using entity translation and title module.

Here is small change to the previous patch. It seems there is an existing condition by default also for checking the node language, which has to be changed to checking the title field language.

<?php
    if (isset($exisiting_condition['field']) && $exisiting_condition['field'] === 'node.language') {
      unset($exisiting_conditions[$key]);
    }
?>

And then we need to check the language in the altered query. I'm using the current language in this case, because the existing query was also always checking the language of the node in current language.

<?php
  global $language;
  $query->leftJoin(
    'field_data_' . $label_field_name,
    't',
    "(t.deleted = 0 AND t.entity_type = :entity_type AND t.entity_id = $base_table.$identifier AND t.language = :language)",
     array(':entity_type' => $entity_name, ':language' => $language->language)
  );
?>

Seems to work for me.

Changing status

#13 solves it for me. Thanks a ton!

Search for nodes now works fine again, with the limitation that only keywords in the main language are found.

If I remove

AND t.language = :language

i can search for (translated) node titles both in main and secondary languages.

I did not like the approach of #13 and earlier patches, to much hassle:
- Why add another query tag?
- Why add it only under special conditions: let the hook check the conditions?
- Why add functionality in the same module using a query alter hook: one of the lasts resorts to use.
- I consider ET and Title as modules that other modules should support out of the box. Thus constructs to check if title is enabled or active are acceptable, even in the main flow of the main module are no code smells. So no separate plugin needed like Linkit Views.

Therefore, I made a smaller and easier to understand patch that adds support for the title module using the entity_info already available (The Title module adds it own info to that info structure). This is a first try, I will probably come up with a follow up shortly, to cover some cases that are not yet covered (e.g. Title module only replacing for some bundles, not all)

I also do not check if the result is in the same language: Linkit doesn't do so with the "old" in-core translation model (of translation sets), so does not have to do so here either. However, as a result, it might present results for which the search string does NOT appear in the label for the current language. This will happen if a translation does contain the search string in its label. I think this is correct behavior, this patch should not add language handling/filtering which is not already available in Linkit, that could be done in a separate issue. Here we should focus on supporting the title module when used in conjunction with the ET translation model.

Bundle handling within an entity type makes it a lot more complicated as there are a lot of cases to be distinguished:
- entity type supports bundles or not
- title module enabled or not
- label property is replaced for all/some/none of the bundles for an entity type

Furthermore, EFQ does not support OR conditions (hence the way the patches above were constructed). So I ended up doing at most 2 queries (some combinations of the above cases will never give results). As this module is already based on merging the results of multiple queries, I don't think this is bad and thus i do not see a reason to go back to the alter_query hook to arrive at 1 (SQL) query.

This patch can be reviewed, the former patch now serves as a simplification that better explains the idea.

I know #13 works as have been using it for about 4 months. I will try to find the time to review the updated code. Am I correct in that there should be no regressions and functionally everything should still work the same?

The patch from #13 solves the problem in a completely different way as #18 does, so there might be differences in the results listed.

some differences that I spotted:
- #13 does filter on the current language, #18 does not, Linkit without these patches does not either. According to #16 this is also not wanted.

- #18 does present the results in the current language, even if the match was in a translation. This looks weird to the user, but changing language handling in the results is not part of this issue (as it is far to complicated to solve here in 1 patch).
- Linkit shows the title of the translation in the results if and only if translation sets are used, otherwise it will not find matches in the current language if that is not the default language (this is what this issue is about)

- #13 does an OR condition in 1 query. As a result, bundles that have title replacement enabled are still also searched for in the title property in the entity table. The inverse (bundles without title replacement enabled are also searched for in the title replacing field) is also true but will not lead to additional results (unless left overs are not correctly delete or marked for deletion).
- #18 does search the title property in the entity table only for bundles that do not have title replacement enabled and searches in the title replacing field table only for bundles that do have title replacement enabled.

- #13 uses a query_alter hook meaning that only SQL database can be used, whereas #18 only uses EFQ features and thus could in principle also be used on non-relational databases. This probably does not have practical consequences, unless e.g. mongo_db can indeed be used in combination with D7 for field storage.

My local tests passed with these settings:
- All taxonomy bundles use title replacement.
- Not all node bundles use title replacement.
- User entity does not define bundles and name is not replaced.
- Managed file entity does not define bundles and name is not replaced.
With these settings, my patch worked fine.

@fietserwin Thanks for the patch! Would be nice if this could get committed. Personally I prefer the patch in #18.

Rerolled the patch againt HEAD, at least for me I got a minor reject.

Rerolled patch in #13 against 7.x-1.5

It does exactly what is needed. I prefer the functionality to the later patch and the logic jives as well. I have not thoroughly tested edge cases but it works with my case wonderfully.

We have some tests that tests the search plugins, and I would really like a tests to extend this functionality.

To test with the title module, we can use

test_dependencies:
  - title

in the info file.

patch from #23 does not apply cleanly
had to patch by hand but it works as expected

Rerolled patch against 3.x-dev

Still needs a test for this.

The patch from #18 is conceptually still better, so IMO we'd better reroll that one.

I agree, I don't understand why one would want to go with the other patch, #18 is of a much higher quality IMHO.

Patch #18 - re-rolled with current 7.x-3.5

Uploading w/ proper name and test

I used the latest dev from linkit (7.x-3.5+10-dev) and the patch #32. Now linkit found nothing.
Before I implement the patch, only with the dev version, linkit found some English / German titles.

Is there any other patch to be implemented for the current dev version?

I use German and English languages, English is the default system language, German the translation source language.

I hit an issue when the query access tags take effect - code like _node_query_node_access_alter() tries to fetch the base table for the access check but the EntityFieldQuery / field_sql_storage_field_storage_query set the field table instead the node table as base table. I'm not quite sure if this points to a deeper issue with EFQ / _node_query_node_access_alter().
However, I was able to fix it by setting the entity type base table into the query metadata - key base_table.
The attached patch was rolled against 7.x-3.x

The 2 year old patches in #32 and #34 applied cleanly to the latest linkit 7.x-3.x-dev, but still needs community review & testing.