#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.
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedMaking note that this one is node query in the title.
Comment #1.0
Anonymous (not verified) CreditAttribution: Anonymous commentedAdding reference to very similar issue.
Comment #2
xjm(Merging "node system" and "node.module" components for 8.x; disregard.)
Comment #3
roderikUpdating the issue summary, since I happened to see many of these @todo's migrate to new files. The above two, plus another one have moved into ForumManager - so assigning to component forum.module.
(And assigning issues which had already been created anyway, to other components.)
By the way, there is more that should be fixed up in ForumManager. Since CommentStatistics is a service now, the {comment_entity_statistics} should not be queried directly anymore. See #2101183: Move {comment_entity_statistics} to proper service.
Comment #4
plachComment #17
quietone CreditAttribution: quietone at PreviousNext commentedForum is approved for removal. See #1898812: [policy] Deprecate forum module for removal in Drupal 11
This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
It will be moved to the contributed extension once the Drupal 11 branch is open.