The 'Add new comment'-link in comment_node_view() always links to the separate page at comment/reply/$node->nid, ignoring the setting of the node type comment style. When set to COMMENT_FORM_BELOW, the link should lead the user to node/$node->nid
$links['comment-add'] = array(
'title' => t('Add new comment'),
'href' => "comment/reply/$node->nid",
'attributes' => array('title' => t('Add a new comment to this page.')),
'fragment' => 'comment-form',
);
The non-teaser display does take the setting into account:
$links['comment-add'] = array(
'title' => t('Add new comment'),
'attributes' => array('title' => t('Share your thoughts and opinions related to this posting.')),
'href' => "node/$node->nid",
'fragment' => 'comment-form',
);
if ($comment_form_location == COMMENT_FORM_SEPARATE_PAGE) {
$links['comment-add']['href'] = "comment/reply/$node->nid";
}
The attached patch copies the behavior to the teaser view for consistend 'add comment' links. I guess it's too late to backport this to D7?
Comments
Comment #1
xjmComment #2
xjmYeah, probably too late for D7.
Thanks for looking into this. Note that the Drupal 8.x patch will need to be rerolled, because the core directory structure for Drupal 8 has now changed. (For more information, see #22336: Move all core Drupal files under a /core folder to improve usability and upgrades). When the patch has been rerolled, please set the issue back to "Needs Review."
Tagging as novice for the task of rerolling the Drupal 8.x patch.
If you need help rerolling this patch, you can come to core office hours or ask in #drupal-gitsupport on IRC.
Comment #3
rjgoldsborough commentedRerolled for d8
Comment #4
rjgoldsborough commentedRerolled for d8
Comment #5
mrharolda commentedNice! Thanks, rjgoldsborough!
Comment #9
oriol_e9gMaybe can we write a test?
Comment #10
oriol_e9gComment #11
jwilson3Here you go, with tests.
Comment #12
jwilson3So, I got the name of the link wrong in the test comment. Should be "Add new comment", not "Add a comment".
Comment #13
xjmThis looks great! There's just one small thing I'd change about the tests:
The assertion messages (last argument) should not be translated. See #500866: [META] remove t() from assert message.
When you revise the patch, could you upload a test-only version and the combined version in the same comment, to expose the failures on testbot without the fix? Thanks!
Comment #14
jwilson3Sadly, a week has passed and no volunteers to summarize #500866: [META] remove t() from assert message. I'm somewhat of of the mind that the onus should be on *that* issue to continue to rebase and find all instances of newly committed offending code. This keeps the commits logical until the new proposed standard actually makes it in. It seems likely based on the size of this issue compared to the size of that issue, that this one will make it in *before* that issue gets a green light. If that is the case, then personally, my vote would go towards committing the patch in #12 that matches current best practices. Whereupon I would be more than happy to then reroll #500866: [META] remove t() from assert message to remove the t() in the piece of code I've written here.
That being said, I'll comply with xjm's request in #13 to remove the t(), (just in case ;) but more specifically, in order to see the fails. The
-tests-only.patchis expected to have various failures. Hope it works ;)Comment #15
xjmThe patch in #14 looks correct. Thanks!
The reason the other issue is NW is for the patch itself there, not the policy change. Also, you could help out by starting a summary yourself. The issue is near 200 comments long so I'm unsurprised no one summarized it yet. It's probably a good hour of work at least. :)
Comment #18
mrharolda commentedLooking good!
Can this be considered a bug in Drupal 7? D7 is going to be around for another couple of years before D8 kicks in. I can't imagine anybody relying on the old behavior.
Huh? Where did those tags came from and how do I remove them?!?
Comment #19
xjmWe eventually figured out that a spammer posted between your post and mine. :)
Unfortunately, I don't think this change is backportable, because it does change an existing behavior, which we generally can't do in a release version of core. (It may be possible to work around the issue in D7 with a contrib module.) Reference: http://drupal.org/node/767608
Comment #20
catchMakes sense to me. Committed/pushed to 8.x.