#1498674: Refactor node properties to multilingual →
has split various fields out from the {node} table into {node_field_data}, which has a row for each node + language.
Since there are now different rows per node, SQL queries which previously used node.status should now use node_field_data.status, for one of the specific language rows. Figuring out how all individual queries could now be improved to make use of language specific properties, was split into followup issues, and @todos were inserted in various parts of the code.
Three of the places where there still is a @todo, have now moved into the ForumManager class.
Remaining tasks
Figure out whether and how the query should work on different language rows in {node_field_data}, dependent on language context.
Change the code or remove the @todos, in 3 places in ForumManager.
Original issue text follows
Problem/Motivation
Simplify code
In 1498674 was the @todo
@todo This should be actually filtering on the desired node language and just fall back to the default language.
On the line in the patch in comment #303:
1249 and 1260.
The line of the final patch might change but that info might help to find them.
For example,
$query
->orderBy('f.sticky', 'DESC')
->orderByHeader($forum_topic_list_header)
- ->condition('n.nid', $nids);
+ ->condition('n.nid', $nids)
+ // @todo This should be actually filtering on the desired node language
+ // and just fall back to the default language.
+ ->condition('n.default_langcode', 1);
Proposed resolution
This should be actually filtering on the desired node language and just fall back to the default language.
User interface changes
No.
API changes
No.