Duplicated rows on admin/content if author is translated

Ouch, probably we need to ensure the join also has the following condition:

user_field_data.default_langcode = 1.

Is adding a filter for user_field_data.langcode = <current content language> a possible workaround?

Can someone post the query which is actually executed. I thought we don't join to the user table ever and just load all the entities on all rows which then loads the user entity and renders a link to it ...

Currently the users_field_data table is joined to show the author name. To do that, a relationship was added to the view which probably causes the duplication.

This patch substitutes the user:name for the 'authored by' field and then sets the formatter to Author. No relationship needed that way (no idea if this has any other impact though). In theory, this should fix the problem.

The query looks like this when using this config

+++ b/core/modules/node/config/optional/views.view.content.yml
@@ -239,25 +239,71 @@ display:
+          settings:
+            link: 0

ok so apparently this export with config manager doesn't pass testing. Removed the offending bit and passes locally now.

This issue maybe could be solved, when view uses language filter according to current interface language. If language is en it will show only en versions for articles, and if it is spanish language it will show spanish nodes.

I made language filter not exposed. I think this is way how admin/content page worked in D7

@martins.kajins that would only remove the node with the non-current language. You would still get a duplicate row for the translated user and the current language node.

Both the node_field_data and user_field_data contain language settings so if you join these two tables, you get duplicate rows (well not exactly duplicate, one for each language combination), that's just the way joins work.

So the only way to prevent duplicate rows is to not do that join (or not store language settings in those tables...), or add more filters to reduce the duplicates. But less joins sounds better then adding more filters that are pointless by default.

Is this a duplicate of #2473989: Lack of dynamic language field / filter makes shipping core views hard to be both compatible with mono and multilingual? At the very least it seems related.

The core committers and Views maintainers (alexpott, xjm, effulgentsia, tim.plunkett, and dawehner) agreed that this is a major issue. It's a prominent and confusing bug on one of core's most important administration forms for multilingual sites. The issue is not critical because the view is still usable and the actual data are not affected.

I also ran into the issue with a site, that depends on translated users. I tested the patch in #11 and it solves the problem of duplicating the rows, as it is removing the JOIN to the user_field_data table.

Do all of the existing sorts/filters/links/etc. that were on admin/content still work with this change? Probably needs manual side-by-side testing

Yes, unfortunately it introduces a regression. The content "Authored by" field is based on the uid and so you'll get confusing results, when sorting by that column. The user would expect it to be sorted by the username, but it's actually by uid:
ORDER BY node_field_data.uid ASC

That might have been one of the reasons for having introduced the relationship.

Hello there, we've having the same issue with an editor with enabled translations, anytime she creates an article it appears duplicated in the content table.

This is kind a benign bug so we don't know which is the best approach, should we apply the patch exposing the incompatibilty @szeidler commented or is this bug expected to be solved with the 8.5 update?

Have we got any info in the status of this issue?

Thanks in advance :)

HI, I found a solution in this post https://www.danbp.org/p/en/node/123

It works for me

Hi MiquelFuster,
Thanks for your link to temporary solve this problem. I confirm that the second point can fix this issue.

#2 said user_field_data.default_langcode = 1
I am guessing it means add a filter criteria (author) User: Default translation (= True)
This solved it in my case

Hello,

If I got the issue right can easily be managed by adding the filter Content: Default Translation(=True) in the content listing page view (admin/structure/views/view/content) and the default translated content will show.

For example, if default translation for particular content is in English (Other translation also available) then it will show only English content.

Thanks,
Kunal Gautam

#30 worked. Thanks.

Confirmed still an issue in 9.5

Added reroll of patch #13 on Drupal 9.4.x. still needs work for comment #34.

@ravi.shankar, thanks for rerolling.

I don't that #13 should have been rerolled. In #15, a maintainer explains why that patch is not the desired approach. I don't understand why #34 needs to be addressed, in that comment @jhodgdon was explaining why the suggestion in the previous comment was already discussed and is not the solution.

I would think that patch needs to follow the direction in #15. And since there isn't a patch for that I am setting this to active.

I can also confirm that #30 solves the issue. We had a confusing list of duplicated content in the admin/content listing when we added an exposed filter for the Author to be able to find the content for certain user more easily. The problematic results were done by a translated user profile.