Problem
When BigPipe (8.1.x rc1) is enabled, and the user is logged in. Disqus comments will not load.
However even when Disqus does not load, the following HTML exists.
<div data-quickedit-field-id="node/24/field_disqus/und/full">
<div id="disqus_thread">
<noscript>
<p>
<a href="http://localhost:8080/node/24">View the discussion thread.</a>
</p>
</noscript>
</div>
</div>Note that the Disqus field is not delivered using the BigPipe mechanism even if BigPipe is active.
Now when BigPipe is enabled, the ajax call in disqus.js that loads embed.js from disqus.com is not executed. (Line 69 in disqus.js)
// Make the AJAX call to get the Disqus comments.
jQuery.ajax({
type: 'GET',
url: '//' + disqus_shortname + '.disqus.com/embed.js',
dataType: 'script',
cache: false
});
If I manually run this code in the console after the page is loaded, it will then load embed.js from disqus.com and the comment will load normally.
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | interdiff-14-23.txt | 496 bytes | Anonymous (not verified) |
| #23 | disqus-2691401-23.patch | 1.87 KB | Anonymous (not verified) |
| #14 | disqus-2691401-1.patch | 1.96 KB | Anonymous (not verified) |
Comments
Comment #1
Anonymous (not verified) commentedztl8702 created an issue. See original summary.
Comment #2
wim leersCross-posting from #2690589-9: Disqus comments not loading when BigPipe is installed:
Comment #3
Anonymous (not verified) commentedYes, it looks like we should re-run the checking after each AJAX call. I am working on a patch now. I am not sure whether simply removing
.once()will work. Probably needs more work.Comment #4
Anonymous (not verified) commentedI put the following debug code inside the disqus behavior, outside
.once():But when I load the page I got the following logs:
It turns out the behavior is indeed called after each AJAX call, however even in the last call (when BigPipe should have already done loading), the disqus setting is still undefined.
This is strange.
Comment #5
Anonymous (not verified) commentedWim Leers, it turns out that
drupalSettings.disqusis never set when BigPipe is enabled.When BigPipe is enabled (logged in), console.log(drupalSettings) returns:
Object { path: Object, pluralDelimiter: "", ajaxPageState: Object, ajaxTrustedUrl: Array[0], bigPipePlaceholderIds: Object, disqusComments: "someid", toolbar: Object, user: Object, dialog: Object, editor: Object }When BigPipe is NOT enabled, console.log(drupalSettings) returns:
Object { path: Object, pluralDelimiter: "", disqusComments: "someid", disqus: Object, user: Object }If we look at the response, disqus settings are not included in both the initial drupalSettings object nor in the second flush by BigPipe.
The
disqusCommentsobject, however, does load no matter BigPipe is enabled or not.Comment #6
wim leersI'll take a quick look.
Comment #7
nod_My guess is missing dependency on
core/drupalSettings.Comment #8
wim leersThat'd be a great guess indeed.
Unassigning, clearly I got sidetracked.
Comment #9
Anonymous (not verified) commentedComment #10
Anonymous (not verified) commented@nod_ Adding
core/drupalSettingstodisqus.libraries.ymldoes not help, as far as I have tested.What I find strange is that the
disqusCommentsproperty is always set indrupalSettings, regardless of whether BigPipe is enabled or not.Comment #11
Anonymous (not verified) commentedUmm... Looks like the callback function for the placeholder of
DisqusElement is not called, which is where thedisqussettings are attached todrupalSettings.Let me see why that happened.
Comment #12
Anonymous (not verified) commentedInterestingly, the placeholder generated by Disqus module has been overridden by BigPipe, but somehow this placeholder does not appears in the final HTML. The Disqus Element is rendered as if it is not served via BigPipe, however its callback function is never called.
In my case, BigPipe replaced two HTML placeholders,
StatusMessages, andDisqusComments; however, onlyStatusMessagesone appears in thepreBody.Comment #13
Anonymous (not verified) commentedOK. I think I have located where the error is.
In
Disqus.php, it does this:I think this causes the Disqus placeholder to be rendered instead of the BigPipe placeholder.
After changing this function to:
The
disqusobject will appear indrupalSettings. Now we just need to fix the javascript.Comment #14
Anonymous (not verified) commentedSo here is the patch.
What I did:
The patch works for me. Please help with testing. Thanks.
Comment #15
skyredwangComment #16
fabianx commentedI think the JS fix is fine, but to remove the properties feels a little wrong.
I think if possible this should use a #builder instead of #pre_render as it clearly can be rendered independently and then the render array inside the builder should have the other properties.
Comment #17
Anonymous (not verified) commented@Fabianx
in
src/Element/Disqus.phpfunction
generatePlaceholderlooks like this:And function
displayDisqusCommentsadds#theme_wrappersand#attributes.and
'title','url','identifier'finally gets set in the callback function.That's why I don't think they need to be set in the first function. Tell me if I am wrong.
Comment #18
slashrsm commentedShould we make sure those are not empty to prevent notices?
At least identifier is actually required. Should we throw an exception if it is not set?
Comment #19
Anonymous (not verified) commented@slashrsm
I think you are right. What really matters is only
'#theme_wrappers'.Comment #20
slashrsm commentedIdentifier seems to be important to, right? And if user doesn't supply title, url or identifier we will get notices in generatePlaceholder().
Comment #21
Anonymous (not verified) commented@slashrsm,
Yes. So we only remove
'#theme_wrappers'.I will test it shortly.
Comment #22
omlx commentedany update ?
Comment #23
Anonymous (not verified) commented@omlx
Sorry I forgot.
A simple fix. Could you try it out?
Comment #24
omlx commented@ztl8702 Thanks, It works for me.
Comment #26
slashrsm commentedCommitted.