Search Views integration - filter needs to join to node_field_data.langcode

Related issue: #2218065: Need to join fields to the entity field data tables, not entity tables, or filtering increases number of results which is the same problem for Field API fields filtering.

Here's a failing test that illustrates this problem. If you run it interactively, you'll see at the last step that the Views output page has both translations shown, even though only one matches the keyword filter.

OK, here's a patch along with the test. I edited the test assert messages so they are less cryptic and more descriptive, but otherwise the test is the same as the one that failed (as expected) in #2. Interdiff attached.

I think this works... For some reason I am unable to run tests in my current D8 install (something about not having an active config directory? I probably need to reinstall or something). But in my testing of the bug itself, the patch fixes the problem as stated in the issue summary. Let's see what the bot says.

Whoops. That wasn't an interdiff. Try this one.

4: 2218057-4.patch queued for re-testing.

Hm. That looks like a legit test failure. Will need some work in that case.

OK, I have no idea what is going on here.

I can reproduce the test failure on my local machine. When the test goes to the "test filter" page, which is supposed to find nodes with "pizza" in them, the page is empty when you look at the debug output of the test -- no links to either node.

However, when I try to do the steps the test is doing on my local site (outside of the test environment), after importing the test view configuration into my local site, the "filter page" works just fine (I can see the "pizza" node link). I thought it might be a permissions problem, but on my local site I can even see this result if I log out, so I don't think that is the problem.

I also added some lines to the test to debug what is happening, where I search for the word "pizza" to make sure it got into the search index, and that works fine (insert these just after the cron run line):

    $this->drupalPostForm('search/node', array('keys' => 'sandwich'), t('Search'));
    $this->assertLink('sandwich', 0, 'English node translation is searchable');
    $this->drupalPostForm('search/node', array('keys' => 'pizza'), t('Search'));
    $this->assertLink('pizza', 0, 'Spanish node translation is searchable');

The debug output for these lines shows the right search results.

The really odd thing is that this test was passing on March 4. Something changed between then and now and now it is failing. :(

Also, just as a note: without the code patch here, as of March 4, the test I wrote for this bug was finding both the "pizza" and the "sandwich" nodes on the filter page (if you look at the test results output in comment #2, you'll see it fails on the line where it's verifying that the "sandwich" link should not be on the page).

When I unpatch my local site and look at the test view page output on my local site (outside of testing), I am still seeing that same behavior: it is supposed to be filtering to nodes containing "pizza", but both the "pizza" ("Spanish") translation and the "sandwich" ("English") translations are being shown (which is the bug that is being reported in this issue). But inside the testing environment, if I run the test it just shows the English "sandwich" node, and not the Spanish "pizza" node.

So, something is definitely different in the test environment and my actual local site, and apparently this change in the testing environment also changed between March 4 and now (and it didn't also change in my local site, which I just reinstalled today from scratch). I wonder what is going on?

OK, I realize the last two comments are fairly confusing. Here's the situation:

a) What the test does:
- Adds Spanish as a language
- Adds a content type, and sets it up for translation
- Adds a node with title "sandwich" in English and "translates" it into Spanish, using title "pizza" in Spanish.
- Runs cron to index for searching.
- Visits a test view page from the view "test_search" (config file: core/modules/views/tests/modules/views_test_config/test_views/views.view.test_search.yml). This view page has a filter for "search keywords: pizza".
- Attempts to verify that the "pizza" Spanish node translation is visible, and that the "sandwich" English node translation is not.
- I also added a few extra lines to the test to verify that using the core search/node page, I can successfully search for both "pizza" and "sandwich" and I see the correct node translations in both cases.

b) On my local site, I reproduced similar steps... The only difference is that I installed using the Standard install profile, and used the built-in "Page" content type instead of a newly-created content type. And I went to Config Import to import the test view. I also tested viewing the test view page as both Anonymous and User 1.

c) As of March 4th, without the code patch, the behavior of both the tests and local site was that on the test view page, both the "sandwich" and "pizza" node variants were visible. And with the code patch, the behavior of both the tests and local site was that on the test view page, just the "pizza" node was visible.

d) As of today, my local test site behaves the same as described in (c).

e) As of today, when running the test: without the code patch, the test view page output shows just the "sandwich" translation. And with the code patch, the test view page output shows no results (just the page title). However, the test lines show that search/node is still working properly -- it is only within Views that things have changed for the worse.

Is that clear? So what I'm trying to figure out is:

1. Why, as of today, does the test behavior not match what I see on my local site?

2. Why is the test behavior different between March 4 and today -- it appears that I cannot see the Spanish node at all when I go to the test view page, although there is no language filter in the view.

OK, that solves the mystery! Probably prior to March, created translations were published by default, and now they are not. And on my local test site, the translation was definitely published. So that would explain why (a) the results changed over time and (b) they are different between the test and my site.

So now we have a viable patch and a passing test. I think this patch is good to go. dawehner do you still think it has problems?

12: 2218057-12.patch queued for re-testing.

I think that you meant to set this to RTBC? If so, I'm +1. If not, set back. Thanks!