#46260 closed defect (bug) (fixed)
5.1 Backwards Compatibility Issue: comment-reply.js
Reported by: | iCaleb | Owned by: | peterwilsoncc |
---|---|---|---|
Milestone: | 5.1 | Priority: | normal |
Severity: | normal | Version: | 5.1 |
Component: | Comments | Keywords: | has-patch commit fixed-major |
Focuses: | Cc: |
Description (last modified by )
tl;dr -> The changes made to comment-reply.js for the 5.1 release cause BC issues when comments are loaded in after the initial page load (via ajax for example). The reply link does not work as expected anymore, and can break commenting completely depending on the implementation.
Issue Description
In WP 5.0 and before, the comment reply links were hardcoded to the onclick event, seen here: https://github.com/WordPress/WordPress/commit/f617a2d6d932e658449cef1b7864fb77080ecd09#diff-3db08a6b98155b349c93a220bc903dceL1670
But in 5.1+ (since #31590), comment-reply.js
initializes by binding these links to the event handler. The problem is though, these links won't exist yet when the script is first loaded since they come in later via ajax.
Replicating / Solutions
I first replicated on a site using a custom ajax implementation, but you can get a similar result using a plugin like https://wordpress.org/plugins/ajax-comment-loading/. Test on 5.0 versus 5.1 and you can see the difference.
To maintain backwards compatibility, the comment reply script should take into consideration that the links won't always be on the page right away when the script is first loaded.
As a fix for individual sites/plugins though (in case somebody stumbles across this ticket), you can call window.addComment.init();
at the end of your ajax callback to ensure the links get bound to the needed event handlers.
Attachments (4)
Change History (18)
#2
@
6 years ago
Researched but untested :)
I think using MutationObserver
with a fallback to DOMNodeInserted
for checking for inserted content and re-initializing will fix this back to IE 9.
#3
follow-up:
↓ 4
@
6 years ago
- Keywords has-patch 2nd-opinion added
46260.diff fixes this by event bubbling, rather than MutationObserver
.
I have no strong preference either way, this is just the approach I took first.
Looking at the code and discussion on #31590, it appears intentional that Ajax comment loaders will need to call window.addComment.init()
, but I couldn't find a devnote to match. @peterwilsoncc, I don't suppose you recall any additional context on this decision?
#4
in reply to:
↑ 3
@
6 years ago
- Owner set to peterwilsoncc
- Status changed from new to accepted
I was in the same two minds for bubbling vs mutation observing. I'll test out the performance of each.
Replying to pento:
@peterwilsoncc, I don't suppose you recall any additional context on this decision?
I don't, I am afraid. I suspect the context was that four years ago I was more willing to break back-compat for many, many sites than I am now and I missed it when I came back to the ticket recently.
#5
@
6 years ago
46260.3.diff is the alternative approach, using MutationObserver
. I haven't implemented a DOMNodeInserted
fallback, I'm fine with IE<11 falling back to the replytocom
comment form.
#6
@
6 years ago
46260.4.diff is almost identical to 46260.3.diff:
- Since tag on
observeChanges()
- Moved
MutationObserver
declaration to avoid re-defintion - Trailing comma removed on
observerOptions
- Minor golfing change to
init()
.
I've tested it with the plugin highlighted but needed to debug the plugin first as it uses some long-lost jQuery attribute selectors.
I considered including MutationObserver
in the cuts the mustard check but ultimately left it out for a little wider browser support for sites loading comments in the traditional WordPress fashion.
#9
@
6 years ago
- Keywords fixed-major added
- Resolution fixed deleted
- Status changed from closed to reopened
Re-opening for back-port consideration.
Adding to 5.1 to be investigated properly.