Comments

larowlan’s picture

Status: Needs review » Postponed (maintainer needs more info)

We need both, one is for the last comment, the other for the author. However the test pass intrigues me.

droplet’s picture

Status: Postponed (maintainer needs more info) » Needs review

for what author ??

for testing & coding side, it never get used:

$query->addExpression('CASE ncs.last_comment_uid WHEN 0 THEN ncs.last_comment_name ELSE u2.name END', 'last_comment_name');

    $topic = $query
      ->fields('ncs', array('last_comment_timestamp', 'last_comment_uid'))
heilop’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +dlatino
catch’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Yep we never actually fetch the uid field from the {node} table here so it is indeed a pointless join.

Committed/pushed to 8.x, moving to 7.x for backport.

droplet’s picture

Status: Patch (to be ported) » Needs review
StatusFileSize
new1.01 KB
andypost’s picture

Status: Needs review » Needs work
+++ b/modules/forum/forum.module
@@ -823,11 +823,10 @@ function forum_forum_load($tid = NULL) {
-    $query->join('users', 'u2', 'ncs.last_comment_uid = u2.uid');
-    $query->addExpression('CASE ncs.last_comment_uid WHEN 0 THEN ncs.last_comment_name ELSE u2.name END', 'last_comment_name');
+    $query->join('users', 'u', 'ncs.last_comment_uid = u.uid');

please don't change alias name because contrib probably already alters this

droplet’s picture

Status: Needs work » Needs review
StatusFileSize
new608 bytes

:)

andypost’s picture

Status: Needs review » Reviewed & tested by the community

thanx, thats much better

David_Rothstein’s picture

Version: 7.x-dev » 8.x-dev
Category: bug » task
Status: Reviewed & tested by the community » Needs review

I don't think it's true that this join is pointless. It's an inner join, which means it guarantees there's actually a matching row in the users table.

By guaranteeing that, it forces the query to be consistent with the one in forum_get_topics(), which also does this join. And we do want them to be consistent (since one query gets you information about the most recently commented-on post and the other shows a list of posts, so it would be pretty weird if the forum overview says "Last post: 5 minutes ago by X" but then you go to the forum and there is no such recently-updated post).

In practice, this can only occur if the node author is a user who no longer exists on the site... so it should be pretty rare. However, we do have situations where a user could have been deleted without the node module's hooks being fired to respond to it, so it definitely can happen.

Moving back for discussion, since the general point is that this query should be consistent with forum_get_topics() but the patch makes it not consistent.

Also, to be honest, I'm not that excited about committing the patch to Drupal 7 either way. It doesn't seem to be an actual bug (or a noticeable performance hit, at least not that I know of?), and as @andypost points out this is an alterable query (in fact, it's a node access query) so we're probably better off not changing those in Drupal 7 unless we have a good reason to.

salvis’s picture

Title: remove unnecessary user join in forum_forum_load » Fix the author names in the forum list
Version: 8.x-dev » 7.x-dev
Category: task » bug
Issue tags: -Quick fix, -Needs backport to D7, -dlatino
StatusFileSize
new1.45 KB

This is broken in D7, and the patch has broken it even more for D8.

Let me explain for D7, because that is less broken — here's what we have:

    // Query "Last Post" information for this forum.
    $query = db_select('node', 'n');
    $query->join('users', 'u1', 'n.uid = u1.uid');
    $query->join('forum', 'f', 'n.vid = f.vid AND f.tid = :tid', array(':tid' => $forum->tid));
    $query->join('node_comment_statistics', 'ncs', 'n.nid = ncs.nid');
    $query->join('users', 'u2', 'ncs.last_comment_uid = u2.uid');
    $query->addExpression('CASE ncs.last_comment_uid WHEN 0 THEN ncs.last_comment_name ELSE u2.name END', 'last_comment_name');

    $topic = $query
      ->fields('ncs', array('last_comment_timestamp', 'last_comment_uid'))
      ->condition('n.status', 1)
      ->orderBy('last_comment_timestamp', 'DESC')
      ->range(0, 1)
      ->addTag('node_access')
      ->execute()
      ->fetchObject();

    // Merge in the "Last Post" information.
    $last_post = new stdClass();
    if (!empty($topic->last_comment_timestamp)) {
      $last_post->created = $topic->last_comment_timestamp;
      $last_post->name = $topic->last_comment_name;
      $last_post->uid = $topic->last_comment_uid;
    }
    $forum->last_post = $last_post;

ncs.last_comment_uid is never 0 (at least I have no such record in my database), so this always returns u2.name, which is the name of the creator rather than the author.

Here's how to reproduce the bug: as admin create a new topic and set Authored by to 'Bob'. Bob's name will show up as the author of the topic, but forum/% will show the admin's name instead.

The code above is obvious nonsense, but the u1/u2 idea is a good one — it has probably worked at some point. The correct code is:

    // Query "Last Post" information for this forum.
    $query = db_select('node', 'n');
    $query->join('users', 'u1', 'n.uid = u1.uid');
    $query->join('forum', 'f', 'n.vid = f.vid AND f.tid = :tid', array(':tid' => $forum->tid));
    $query->join('node_comment_statistics', 'ncs', 'n.nid = ncs.nid');
    $query->join('users', 'u2', 'ncs.last_comment_uid = u2.uid');
    $query->addExpression('CASE ncs.comment_count WHEN 0 THEN u1.name ELSE u2.name END', 'name');   // FIX
    $query->addExpression('CASE ncs.comment_count WHEN 0 THEN u1.uid ELSE u2.uid END', 'uid');      // FIX

    $topic = $query
      ->fields('ncs', array('last_comment_timestamp'))   // FIX
      ->condition('n.status', 1)
      ->orderBy('last_comment_timestamp', 'DESC')
      ->range(0, 1)
      ->addTag('node_access')
      ->execute()
      ->fetchObject();

    // Merge in the "Last Post" information.
    $last_post = new stdClass();
    if (!empty($topic->last_comment_timestamp)) {
      $last_post->created = $topic->last_comment_timestamp;
      $last_post->name = $topic->name;   // FIX
      $last_post->uid = $topic->uid;     // FIX
    }
    $forum->last_post = $last_post;

We must check the comment_count! If there are no comments, then u1.uid / n.uid is the one to use, and only if there is at least one comment we get the comment author in u2.uid.

Besides the name we also need the uid. It is used to turn the user name on forum/% into a link to the user's profile page.

Here's the patch for D7 as explained above. Let's see what the testbot thinks of it.

(I know we'll need D8 first, and we'll need tests, obviously.)

salvis’s picture

Version: 7.x-dev » 8.x-dev
StatusFileSize
new1.67 KB

Good, now D8...

salvis’s picture

#11: forum_author.1377468.11.D8.patch queued for re-testing.

salvis’s picture

#11: forum_author.1377468.11.D8.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, forum_author.1377468.11.D8.patch, failed testing.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • catch committed 9e2223c on 8.3.x
    Issue #1377468 by droplet: Fixed remove unnecessary user join in...

  • catch committed 9e2223c on 8.3.x
    Issue #1377468 by droplet: Fixed remove unnecessary user join in...

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

  • catch committed 9e2223c on 8.4.x
    Issue #1377468 by droplet: Fixed remove unnecessary user join in...

  • catch committed 9e2223c on 8.4.x
    Issue #1377468 by droplet: Fixed remove unnecessary user join in...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dillix’s picture

Issue summary: View changes
Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.