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).
Comment | File | Size | Author |
---|---|---|---|
#14 | comment_permalink-2730973-14-test_only_FAIL.patch | 1.84 KB | Wim Leers |
#14 | comment_permalink-2730973-14.patch | 3.21 KB | Wim Leers |
Comments
Comment #2
J.R. CreditAttribution: J.R. as a volunteer commentedComment #3
larowlanThanks for the detailed report
Comment #4
larowlanCode 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
In
\Drupal\comment\Controller\CommentController::commentPermalink
- I suspect we need to addafter
$response->addCacheableDependency($subrequest_url);
Working on it
Comment #5
J.R. CreditAttribution: J.R. as a volunteer commented(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).
Comment #6
larowlanlooking for red/green
Comment #7
larowlanHi @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
Comment #9
J.R. CreditAttribution: J.R. as a volunteer commentedLooking forward to release which contains it ..
Thanks for the work and hints: started to connect to local Drupal community.
(Edited: removed obsolete)
Comment #10
J.R. CreditAttribution: J.R. as a volunteer commentedI 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 ..).
Comment #11
J.R. CreditAttribution: J.R. as a volunteer commentedPatch 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.
Comment #12
andypost@JonasRMuc great find/report!
Overall this looks like hotfix, for long term fix suppose setting page argument twice on passed request is wrong
Looks strange to pass page argument twice
Makes sense to check where pager searching for page...
Comment #13
andypostAlso #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
Comment #14
Wim LeersI 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.This is not necessary; even the
testing
install profile installs this module by default.Comment #16
Wim LeersPassed & failed as expected! :)
Comment #17
andypostThanx Win!
Comment #18
larowlanMaybe we should we be doing
setOption('query', $request->query->all())
instead of special casingpage
- thoughts?Comment #19
larowlanActually, nevermind, $page isn't in request->query - so this is fine - rtbc +1
Comment #22
catchCommitted/pushed to 8.3.x and cherry-picked to 8.2.x. Thanks!