Using Octopress/Jekyll, but can't get embedded comments to work
I'm using Octopress, which is just based around Jekyll (it's an older version, 2.5.3). I've followed the Jekyll instructions and have gotten as far as seeing TEST001 on a post. However, there's no comment form. I just see:
I had to tweak the Jekyll source to get it to work (put all the {$ ... $} on the same lines), but I can't see anything obviously wrong with it. The Javascript source is where it should be and points to the correct address. I'm running it locally via rake preview, but I have http://localhost:4000/ added to my "allow embedding from" sites. What should I do next?
- DIn reply todetly⬆:Jason @detly
Just checked using the live site instead of
localhost, so I don't think it's that. Copypasting the URL straight from the page source works.Is it possible there's a JS dependency I need?
KajMagnus @KajMagnus2018-04-21 06:38:52.219ZNo, everything that's needed is included the
https://cdn.talkyard.net/-/talkyard-comments.min.jsscript.
- DIn reply todetly⬆:Jason @detly
The
iframeseems to be embedded. There's a whole document in there. It's just... invisible? When I copypaste the link from theiframesrcattribute I end up at a Talkyard page. It's got no comments or form in it, but the sidebar and header are visible.There's a link in the sidebar, "Comments for [my domain]", but the link is to
[my domain]/-1which is definitely not something that exists. Is that related? - DIn reply todetly⬆:Jason @detly
(Sorry, I'm going to use this thread as a notepad for debugging now, don't think I'm trying to overwhelm you with messages here!)
Inspecting the elements of the rendered page (using
ctrl+shift+cin Chrome) and comparing to one of your help pages, it looks like mine is missing a whole bunch of divs under<div id="dwPosts">eg. under yours, the next div down is<div class="esPage esPage-Compact s_PT-5">. On my page, it's just an un-classed, un-id'ed<div>. Weird.I also get a JS error consistently:
talkyard-comments.min.js:formatted:684 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://comments-for-[my-domain].talkyard.net') does not match the recipient window's origin ('http://localhost:4000').Looking around the internet for similar problems with iframes, it seems that it's related to trying to send messages to the iframe before it's loaded... does this sound plausible?I will keep digging.
- KajMagnus @KajMagnus2018-04-21 06:42:29.192Z
I think it's good that you posted all these messages :- ) more info for me when looking into this = good, I think. I could reproduce the error you got above when I ran a local web server on a port other than 4000 — I posted another comment here about that with more details
In reply todetly⬆:KajMagnus @KajMagnus2018-04-21 06:36:17.975ZI'm running it locally via
rake preview, but I havehttp://localhost:4000added to my "allow embedding from" sitesWhich port does Rake listen on? If it's something else than 4000, then
http://localhost:4000should instead behttp://localhost:NNNNwhere NNNN is that port number.I wrote 4000 because I had a look at Jekyll and apparently when previewing on localhost, it by default uses port 4000. I was thinking Octopress also used 4000 by default.
I tested myself, and if I start a http server on my laptop that listens on
localhost:4000, then I'm able to embed your website & the comments stuff appears. But if instead I start my http server onlocalhost:8004(i.e. a different port), then I get the same error as the one you mention below:Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://comments-for- ... .talkyard.net') does not match the recipient window's origin ('null').What to do: You could either start Octopress on port 4000, or edit the config value and change
http://localhost:4000to the port Octopress listens to.- DJason @detly
Rake's definitely listening on 4000. Octopress isn't a live part of it, it's just a bunch of Jekyll plugins really.
I wonder if there's a latency issue — I'm viewing the page from Australia, so if there's a lot of latency to retrieve the Talkyard iframe for me but not for you, maybe that's causing it?
I'm happy to put Talkyard on a live site and point you to it, but I'd rather organise that privately in case we need to break things to identify the problem.
- KajMagnus @KajMagnus2018-04-21 10:16:40.219Z
Ok yes a live site sounds helpful. You can send me a private message if you click my username.
Hmm I'm getting the impression that the iframe has loaded with some contents, but ... that something still doesn't work :- /
The error message you get and I got are a tiny bit different: my ends with
... recipient window's origin ('null')and your with... origin ('http://localhost:4000').I googled a bit, and seems my error happens if the iframe didn't load at all. So apparently the error I "reproduced" was actually not the problem that's happening in your case.I don't think latency is related to this.
postMessageisn't involved in the iframe loading & showing the Reply button.All log messages that gets logged, during page load, in the Chrome dev console, would be interesting. (The
talkyard-comments.min.jsscript logs some debug messages like:iframe-parent: startandiframe-parent: loadCommentsCreateEditor()etc ...)I started a local Jekyll server and the iframe loads properly in my case (the Reply button appears, no errors in the console).
Do you use something like HTTPS Everywhere? or other Chrome extensions?
If you try Firefox, then do you see the same error?
Or Chrome in Incognito mode? (ctrl+shit+N)- DJason @detly
No extension like HTTPS Everywhere. I use AdBlockPlus but I disabled it to test this. Same issue in Firefox, and in Chrome incognito mode.
I'll see about getting some log messages.
- DIn reply todetly⬆:Jason @detly
We eventually figured this out in a private message thread, but I had a trailing slash on my
talkyard_server_urland that was causing problems! Removing it resulted in the comments thread appearing as expected. Phew!- KajMagnus @KajMagnus2018-04-23 14:07:37.206Z
Thanks for the info you provided that made it possible to find the bug :- )
(Once I've deployed the next server version, things will work also with a trailing slash.)
- Progresswith handling this problem