8.1.1: comment link uses first cached page of comments;
links to comments on other pages then refer to wrong page.

Repeatable: always
OS: Ubuntu 14.04.4 LTS‬
PHP: 5.5.9+dfsg-1ubuntu4.16
Msysl: 5.5.49-0ubuntu0.14.04.1

Prepare test:
- Install standard, english 8.1.1.
- As admin, create 1 article (node/1)
- Create 15 comments with title C1, .., C15 for the article
- In article content type, modify comments field to show 10 (not 50) comments per page
- For reproducing, use two tabs:
- - E) Effect: one for filling the cache and checking the effect of that
- - C) Cache: one for clearing cache (administration, configuration, performance, button clear cache)

How to reproduce, Actual Results:

Case 1:
- E) goto home page
- C) clear cache
- E) click article link
- E) navigate to page 2 of the comments using pager
- E) click permalink of a comment, say C13 (you created 15 comments)
*1E) /comment/13 is "displayed": the first page of comments (with C3) is displayed (C13 is on page 2)

Case 2 (variation)
- E) goto home page
- E) click article link
- E) navigate to page 2 of the comments
- C) clear cache
- E) refresh page (with page=1 in the url, the second page of comments)
- E) navigate back to page 0 of the comments using the pager
- E) click on any comment title, say C3
*2E) C3 is shown (as expected)

Case 3 (variation)
- E) goto home page
- C) clear cache
- E) display e.g. (yourdomain)/comment/13 (directly via browser address toolbar)
- E) C13 is displayed (as expected: first user is lucky!)
- E) go back to page 0 using pager
- E) Click on C3 (title)
*3E) page 1 of the comments is shown (C13 is visible, not C3)

Expected results (see inline in Actal results too)
*1E) show page 1 with C13
*2E) show page: this is ok. Accessing the page via pager seems to be different.
*3E) show page 0, with C3 visible

Note: you can also use permalinks instead: this is how I discovered it, see below.
--
Analysis: as an attempt of interpretation
(of a newbie: I just went live with my 8.1.1 from migrated Ning2 because of emergency):
a) referencing comments directly in the cache system seems to set the page
which is used for subsequent
b) referencing the page via pager does not seem to set the cache mentioned in a)

--
Motivation:
I discovered this via the migrated link directories I have in my migrated site:
users click, and they do not get to the collected content comment,
but to the content page of the comment the first user after cache clear clicked.
Since I have big threads and 1500 internal links, this matters for me.
--
This is my first issue: please have mercy if I made any mistakes for doing so ..
(I will publish my migration (like the one for D7) in GPL,
and I am grateful to drupal community, yet I know very little, at least not yet).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JonasMuc created an issue. See original summary.

J.R.’s picture

Issue summary: View changes
larowlan’s picture

Title: comment, link, paged, cache problem » Comment permalinks are cached incorrectly when multiple pages exist
Version: 8.1.1 » 8.1.x-dev
Issue tags: -comment, -link, -paged, -cache +Needs tests

Thanks for the detailed report

larowlan’s picture

Assigned: Unassigned » larowlan

Code to look at here is \Drupal\comment\Controller\CommentController::commentPermalink

Test coverage should be added to \Drupal\comment\Tests\CommentPagerTest

The page to view is calculated in \Drupal\comment\CommentStorage::getDisplayOrdinal

We call

$response->addCacheableDependency($subrequest_url);

In \Drupal\comment\Controller\CommentController::commentPermalink - I suspect we need to add

$response->getCacheableMetadata()->addCacheContexts('url');

after $response->addCacheableDependency($subrequest_url);

Working on it

J.R.’s picture

(Edit: removed obsolete)

I know this is a fact oriented issue queue,
but let me express my very deep gratefulness:
this is the last major (for me) bug with my emergency migration.
I will now enter Drupal contribution in a more efficient way,
as can be seen from documentation how to contribute ..
(I would have had to read/try spare time months to find this:
I hope, that I will be able to help more deeply in the future:
with this fix (or it's modifications) I can now move
to publish my migration as a starter kit for Ning2 > D8:
this is probably the best thing I can do now to help Drupal,
(edit): see my profile for details).

larowlan’s picture

Assigned: larowlan » Unassigned
Status: Active » Needs review
Issue tags: -Needs tests
FileSize
2.04 KB
3.13 KB

looking for red/green

larowlan’s picture

Hi @JonasMuc

FWIW, say hi to the community on IRC in #drupal-contribute, there is an active local user group in your part of the world - http://www.meetup.com/en-AU/Munchen-Drupal-User-Group-Meetup/

Lee

The last submitted patch, 6: 2730973-permalink-cache.fail_.patch, failed testing.

J.R.’s picture

Looking forward to release which contains it ..

Thanks for the work and hints: started to connect to local Drupal community.

(Edited: removed obsolete)

J.R.’s picture

I installed a clean standard 8.1.3.

1) repeated steps from issue: still there in 8.1.3

2) applied 2730973-permalink-cache.pass_.patch from #6
results for Case 1 and Case 3 from the issue switch to expected behavior
and Case 2 remains at expected behavior.

After checking the Cases I also watched table cache_render
to see if it grows if comments on one page are (newly) clicked
or repeatedly clicked: the number remained constant.
--
Also, I have my (very small, 330 users) production site patched
(only the functional line, not the test, patched manually)
running with the patch for almost three weeks now
and it worked (with 8.1.2 and 8.1.3): I have so many
links and very long threads (garden reports for one season ..)
that this really helped fix my site (users were confused with bug ..).

J.R.’s picture

Patch works with 8.1.7 for some time in my production site
(I cannot yet review the code (too beginner), so I report it's still working).

---
@larowlan : visited Munich Drupal User Group now twice:
thanks for the hint! There is a DrupalCamp in Munich
in December: I will attend and help if possible.

andypost’s picture

@JonasRMuc great find/report!

Overall this looks like hotfix, for long term fix suppose setting page argument twice on passed request is wrong

+++ b/core/modules/comment/src/Controller/CommentController.php
@@ -125,7 +125,7 @@ public function commentPermalink(Request $request, CommentInterface $comment) {
-      $subrequest_url = $entity->urlInfo()->toString(TRUE);
+      $subrequest_url = $entity->urlInfo()->setOption('query', ['page' => $page])->toString(TRUE);
       $redirect_request = Request::create($subrequest_url->getGeneratedUrl(), 'GET', $request->query->all(), $request->cookies->all(), array(), $request->server->all());
       $redirect_request->query->set('page', $page);

Looks strange to pass page argument twice
Makes sense to check where pager searching for page...

andypost’s picture

Also #4 is a good pointer about cache contexts, if some contrib will provide comment settings (pager per user - like d6 was) then there should be a place to add other contexts

While we can cache this redirects (subrequests) we need to make sure that comments reordered when some comment deleted from this entity

Wim Leers’s picture

I agree with @andypost's concerns. So… why don't we just let Request::create() handle the populating of $request->query for us? Then there's no duplication. Tests still pass.

+++ b/core/modules/comment/src/Tests/CommentPagerTest.php
@@ -12,6 +12,9 @@
+  public static $modules = ['dynamic_page_cache'];

This is not necessary; even the testing install profile installs this module by default.

Status: Needs review » Needs work

The last submitted patch, 14: comment_permalink-2730973-14-test_only_FAIL.patch, failed testing.

Wim Leers’s picture

Status: Needs work » Needs review

Passed & failed as expected! :)

andypost’s picture

Status: Needs review » Reviewed & tested by the community

Thanx Win!

larowlan’s picture

+++ b/core/modules/comment/src/Controller/CommentController.php
@@ -125,9 +125,8 @@ public function commentPermalink(Request $request, CommentInterface $comment) {
+      $subrequest_url = $entity->urlInfo()->setOption('query', ['page' => $page])->toString(TRUE);

Maybe we should we be doing setOption('query', $request->query->all()) instead of special casing page - thoughts?

larowlan’s picture

Actually, nevermind, $page isn't in request->query - so this is fine - rtbc +1

  • catch committed 35778ab on 8.3.x
    Issue #2730973 by Wim Leers, larowlan, JonasRMuc, andypost: Comment...

  • catch committed 36bb9ee on 8.2.x
    Issue #2730973 by Wim Leers, larowlan, JonasRMuc, andypost: Comment...
catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!

Status: Fixed » Closed (fixed)

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