izuzak.github.com
izuzak.github.com copied to clipboard
izuzak
(post comments) GitHub hosted comments for GitHub hosted blogs
This issue is reserved for comments on the blog post GitHub hosted comments for GitHub hosted blogs. Leave a comment below and it will show up on the blog post's Web page. Thanks!
Amazing!
Here's an issue for ya: justification on your article text! Scroll through your article again to see where it bites nastily
Thanks, Tom and Mislav! I love that GitHub is so hackable that pulling this off was quite easy -- keep it up!
Whoa... the new GitHub API (v3) is awesome! The Issues API directly supports fetching the HTML rendering of a comment's Markdown source so there's no need to do that rendering manually on the client side (using the Showdown lib)! I've updated the post to highlight this awesomeness :)
Just as a heads-up, this seems to have broken at some point… each comment body only shows up as “undefined” when I read the blog post page.
Thanks -- looks like it got broken as a result of a Comments v3 API bug, which I just reported http://support.github.com/discussions/api/365-comments-api-v3-broken-not-returning-comment-bodies.
This is great. I only wish it was possible to leave anonymous comments too... Requiring github account is waaay too geeky for most people out there (admit it, we are a minority here).
I really like this idea but can we take it to the next level? Would it be possible to render a comment form at the end of the page along with a captcha? Would it be possible to have a captcha web service that makes the submit comment on your behalf? This way you can still keep your blog as a client side app with no backend. It would be all that hard to write such a web service and host it on cloud foundry.
@Pyrolistical -- that's a cool ided! And you're right, it wouldn't be hard to write such a web service. However, that still introduces another component into the picture which someone has to maintain, because if it goes down - "no commenting for you"! Also, you could still bypass the captcha by going directly to the github issues page and commenting there.
In general, I tend to think that captchas are not needed because the commenting system is tied to GitHub and only GitHub account holders can comment. Therefore, if someone starts spamming GitHub issue pages - you can be sure that the GitHub crew will do a much better job of chasing such accounts down and stopping them than any captcha system.
@ppanyukov Sorry for not answering before. You're right -- anonymous comments would be cool. But using OpenID to login into GitHub would be even cooler. Until then, people will just have to learn to love GitHub :)
Hi @izuzak! I've played around with your pretty cool commenting system. I changed it to get HTML from issue tracker. The only thing unclear for me: does my hack work with some versions of Chrome. Please look at _layouts/post-old.html from my repository visconte.github.com. You need in addition the following files:
-
css/comments-old.css--- extracted part of your CSS for comments, I made it a bit shorter. -
/javascript/jquery.xdomainajax.jsfrom there provides cross-domain AJAX. -
/images/modules/comments/metabar.gif--- just a copy from GitHub.
I don't intend to keep these files always, so don't forget to copy files you need. I think the further step for commenting system is to make a commenting form on post's page. For instanse, preview can be done with GFM JavaScript (maybe the preview is not necessary). After comment is sent, it can be edit from post's page using a JSON request. However, this requires user authentication on post's page. Yes, GitHub allows to do this task as well, but I see huge code size should be made.
Hi @visconte! :) That's very cool, thanks for finding the time to work on that and write up a comment! It took me a while to understand what you actually mean by "get HTML from issue tracker" i.e. that you mean directly getting the comments in HTML format without calling the showdown markdown converter.
As it turns out, your solution only partially solves the problem. Furthermore, the "jquery.xdomainajax.js" you are using is useless as it is not being used at all when you make your $.ajax request. However, your comment made me look at the GitHub API documentation again, and what I found there is something I've been waiting for for a long time and which solves the problem of fetching HTML comments completely. Let me explain these things step by step.
First, why was there a problem with fetching issue comments in HTML?
The GitHub API does enable setting the desired mime type (e.g. application/vnd.github.VERSION.html+json for HTML), but only through HTTP headers. In a browser, you can set HTTP headers only for XmlHttpRequests, which are subject to the same origin policy. Because XmlHttpRequests are subject to the same origin policy, you can either make these requests to server resources on the same domain (e.g. you can make a request from visconte.github.com/test1 to visconte.github.com/test2, but you can't make a request to foo.github.com), or to server resources on other domains if they use the CORS specification which lets you make cross-domain requests. Until recently, the GitHub API didn't support CORS, so I've had to use JSONP to communicate with the GitHub API. However, JSONP doesn't enable you to define the HTTP headers in order to specify the Accept header, which consequently doesn't enable me to directly fetch the HTML version of comments.
Second, why does your solution work?
The jquery.xdomainajax.js library which you included gets around the same origin policy by using a proxy component, and in this case - the proxy is a Yahoo YQL server. Using that proxy, the script can make cross-origin calls. However, if you look more closely at the HTTP requests sent by the browser when fetching comments for your blog, you will see that the script is not being used at all! Rather, the GitHub API is contacted directly and the it returns the comments as you expected. Here are the reqest and response sent by the browser when visiting your blog:
Request
GET /repos/visconte/visconte.github.com/issues/1/comments HTTP/1.1
Host: api.github.com
Connection: keep-alive
Origin: http://visconte.github.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.934.0 Safari/535.8
Accept: application/vnd.github.html+json
Referer: http://visconte.github.com/2011/08/14/github-hosted-comments-for-github-pages.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,hr;q=0.6
Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3
Response
HTTP/1.1 200 OK
Server: nginx/1.0.4
Date: Fri, 11 Nov 2011 10:15:55 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Status: 200 OK
X-RateLimit-Limit: 5000
ETag: "115ddd57cbaaf75b5cfa7c9c385afd88"
Access-Control-Expose-Headers: Link, X-RateLimit-Limit, X-RateLimit-Remaining, X-OAuth-Scopes, X-Accepted-OAuth-Scopes
Access-Control-Allow-Origin: http://visconte.github.com
X-RateLimit-Remaining: 4995
Access-Control-Allow-Credentials: true
Content-Encoding: gzip
Notice the Origin header in the request and the Access-Control-Allow-Origin in the response. The Origin header specifies the domain from which the request originated, while the Access-Control-Allow-Origin specifies the domain which is allowed by the server to make the request. Notice that these two are the same in your case. Therefore, your solution is working because GitHub has recently enabeled CORS in such a way that the API enables GitHub sub-domains to access the GitHub API. In other words, if you make a call to api.github.com from visconte.github.com, that request succeeds because GitHub has enabeled CORS for XmlHttpRequest and for *.github.com subdomain, and for no other reason. Edit: this turns out NOT to be true. GitHub does NOT enable CORS for *.github.com by default. You have to add each CORS supported domain as an OAuth application. See comments below for an explanation.
Third, and most important, why is your solution not general enough?
Your solution works because your blog is hosted on a github subdomain (visconte.github.com). However, this is not the case for my blog which is hosted on ivanzuzak.info. Therefore, until 20 minutes ago, if you made a request to api.github.com from my blog ivanzuzak.info, that request would fail because GitHub API CORS enables request only from *.github.com. In other words, any blog with a custom domain cannot use your approach and needs something else.
How did I solve the problem? Well, notice that the GitHub API documentation on CORS says that you can extend the list of domains which the GitHub CORS allows for cross-origin requests, by registering your site as an OAuth application. Therefore, everything that needs to be done for sites that use custom domains is to register the site as an OAuth application for using the API. This is what I've done and now I can make cross origin request from ivanzuzak.info to api.github.com!
I'll update my blog post to include a more detailed description of this process. Let me know if this wasn't clear enough :).
Also -- your solution has nothing to do with browsers (or at least - it shouldn't). It should either work in all browsers, or not work in any browser.
Thank you for the answer! You are right, jquery.xdomainajax.js is not necessary. Are you sure that GitHub has recently enabeled CORS in such a way that the API enables GitHub sub-domains to access the GitHub API? In fact, I also registered my blog as OAuth application, and as I remember then my solution started working in a while. So the registration is needed in any way. Sorry, I didn't pay attention to this fact in my previous comment.
Ah, you're right and I was wrong! Thanks! GitHub doesn't enable CORS by default for *.github.com domains. I assumed it did because it worked for your site and I assumed you didn't register your site as an OAuth application. (I'll edit my comment to reflect this).
I guess we both came to the same conclusion, after all :)
((Not exactly what I need. And yet,)) that's just a piece of a Righteous Hack! :+1:
Do you have an automated way of creating the post issues, or do you do it by hand each time? The latter seems like a bit of a pain.
@MarkLodato See "Create an issue" at http://developer.github.com/v3/issues/ Also, pull requests are just branches in a separate ref space - you may also check if a non pull request issue might be accessible this way, then perhaps plain git would suffice.
@lamvak I meant, is there some existing script that I can run whenever creating a new post that automatically creates the issue for me? I'm interested in copying @izuzak's site verbatim; I don't feel like figuring all this stuff out myself. :)
thank you @izuzak for posting this guide, I just start implementing it on my blog noconformity.com
@MarkLodato Yep, it is a bit of a pain; might even be the reason why I don't blog as much as before :smile:.
Unfortunately, I don't have such a script, but I'd totally accept a pull request if you (or someone else) build it. I could put something together over the weekend if you don't want to bother with it, though.
If you are using octopress for your blog...
1: Create a custom.css and add @izuzak styles to the file.
2: Modify source/_includes/head.html as follows to include the custom stylesheet:
<link href="{{ root_url }}/stylesheets/custom.css" media="screen, projection" rel="stylesheet" type="text/css">
3: Because we need jQuery, Modify source/_includes/custom/head.html as follows:
<script type="text/javascript" src="http://cdnjs.cloudflare.com/ajax/libs/jquery/2.0.3/jquery.min.js"></script>
4: Because the latest stable of octopress uses ender, Modify source/_layouts/post.html as follows. Make sure to update it to your correct github account and path:
<!-- Use GitHub 4 Comments -->
<section>
<h1>Comments</h1>
Want to leave a comment? Visit <a href="https://github.com/chrishough/myblog/issues/{{page.commentIssueId}}"> this post's issue page on GitHub</a>.
<div id="comments"></div>
</section>
<script type="text/javascript" src="http://cdnjs.cloudflare.com/ajax/libs/datejs/1.0/date.min.js"></script>
<script type="text/javascript">
//------------------------------------------------------------------------------------------------
$.noConflict();
jQuery(document).ready(function($) {
//------------------------------------------------------------------------------------------------
function loadComments(data) {
for (var i=0; i<data.length; i++) {
var cuser = data[i].user.login;
var cuserlink = "https://www.github.com/" + data[i].user.login;
var clink = "https://github.com/chrishough/myblog/issues/{{page.commentIssueId}}#issuecomment-" + data[i].url.substring(data[i].url.lastIndexOf("/")+1);
var cbody = data[i].body_html;
var cavatarlink = data[i].user.avatar_url;
var cdate = Date.parse(data[i].created_at).toString("yyyy-MM-dd HH:mm:ss");
$("#comments").append("<div class='comment'><div class='commentheader'><div class='commentgravatar'>" + '<img src="' + cavatarlink + '" alt="" width="20" height="20">' + "</div><a class='commentuser' href=\""+ cuserlink + "\">" + cuser + "</a><a class='commentdate' href=\"" + clink + "\">" + cdate + "</a></div><div class='commentbody'>" + cbody + "</div></div>");
}
}
function getComments() {
$.ajax("https://api.github.com/repos/chrishough/myblog/issues/{{page.commentIssueId}}/comments", {
headers: {Accept: "application/vnd.github.full+json"},
cache: false,
async: false,
dataType: "json",
success: function(json){
loadComments(json);
}
});
}
getComments();
//------------------------------------------------------------------------------------------------
});
//------------------------------------------------------------------------------------------------
</script>
@hit9 on the current version of octopress that will fail. please see my $.noConflict(); section above. the new version of octopress will be using jquery instead of ender.
@MarkLodato yes, I do plan on setting that up this weekend. Stay tuned :)
after further review, I may need a bit of help with the plug in @MarkLodato, are you game?
@chrishough Well, I've never used octopress so I don't know how much help I'll be, but sure. Send me an email at [email protected].
Thanks for sharing, Ivan!
FWIW, GitHub Enterprise users can use the same technique with a small change in the API endpoint pattern:
https://[enterpriseHost]/api/v3/repos/[owner]/[repo]/issues/{{page.commentIssueId}}/comments
@stedman That's a great tip -- thanks! :zap: GitHub Enterprise is :rocket:
Also, I'm totally open to including this tip in the blog post itself, so if you want to make a pull requests that adds it someplace - I'd be more than happy to accept it. :+1:
@izuzak thanks -- pull request done!
Also, it looks like this post has surpassed the default max of 30 items per request. Fortunately, it looks like one can easily increase the per_page parameter or add pagination.
Thanks @stedman -- merged! :sailboat:
And thanks for noticing that I'm hitting the default pagination limit. I'll get that fixed :+1:
https://github.com/account/applications/new is now https://github.com/settings/applications/new AFAICT (on the link "GitHub form for registering OAuth applications").
Thanks for this post!
@rustyrussell Yep, you're right -- thanks! :heart_decoration: Link updated. :bug: :hammer:
I suggest editing the layout file (the one with <div id="comments">), adding Liquid code so that the comments area only appears if the page actually contains a commentIssueId tag. For instance I just imported about 30 blog posts from BlogSpot to GitHub and I ain't opening an issue for each one...
@qwertie That's a neat idea -- thanks! :zap: If you want to make a pull request which makes that change -- I'd be happy to merge it.
I don't have time [feel like] to make a pull request but I packaged up the code into comments.html and added these instructions on my own blog:
-
Add configuration to
/_config.yml:github: user: qwertie project: loyc -
In
_layouts/default.html, includecomments.htmlbelow the content:... {{ content }} {% include comments.html %} </div> </body> -
Add my copy of
comments.htmlunchanged to your/_includesfolder, and addcomments.cssunchanged to/res/css(oh, you don't have a/res/cssfolder? Either create that folder, or putcomments.csswherever you put css files and changecomments.htmlto point to the new location.) -
To add comments to a page, create an issue in your github project (with whatever name and description you want) and then set
commentIssueIdline in the front matter of your blog post to match the issue:--- layout: post title: "Blogging on GitHub" commentIssueId: 42 --- -
Ivan says you also have to register an "OAuth application", so I did that for
loyc.net, but comments are still working when I look at my Jekyll preview atlocalhost:4000.
Just implemented your solution on my blog over at http://michael.duergner.com - Love it and it's just the right amount of geekness ;-)
I hit a problem with the scripts imported from ajax.googleapis.com and datejs.googlecode.com; because http is used to load these scripts Firefox will not use them on an https page. Both are served over https too, and those work fine. Posting this to help other folks debug this issue.
I have some news that folks might like: I created a small repository called ghpages-ghcomments that adds GitHub comments to pure gh-pages sites, no Jekyll plug-ins required.
Here is an example post with comments.
Features:
- @MarkLodato and @qwertie: it uses git hooks to automate the creation of issues. Pushing a file from _posts will create an issue for it if one doesn't exist.
- @qwertie: it handles posts without comments.
- @stedman: it follows GitHub's pagination of comments (eg it can load more than 30 comments).
- @xhila: it's ready and tailored for new Jekyll sites.
- @Pyrolistical: while a reader still can't leave a comment from your site, the bottom of each post has a link that places your reader at the 'enter comment' field for the post's GitHub issue.
- @jbytheway: it doesn't use AJAX or jQuery, just built-in JavaScript.
- @izuzak: it doesn't need an OAuth application (now that GitHub uses
Access-Control-Allow-Origin: *for CORS).
Read more if you like, or set it up for your site.
Update:
@Pyrolistical and @MarkLodato: readers can now leave comments on the page.
Here's a demo: http://downtothewire.io/gpgc-test/2013/12/31/whats-jekyll/
This is really great way to hack the comment! I've already try it on my site, besides a custom google search for your blog maybe better for people to find things interested.
~~Just as an idea could the file comments feature be used instead of issues?~~ wait that's only on commits, wont help here.
good :).
Will you share your thoughts about having the blog itself to the original issue?
Very cool. I'm new to GitHub and was poking around on my repository and wondered "I wonder if this issues thingy could be used for comments?" A quick Google search brought me to your post on just that topic. Great work.
Seeing...
First, for each blog post you plan to publish, create an issue in your blog's GitHub repository issue tracker.
I'm assuming that's a by hand thing. I think someone needs to find a way to automate that. And even better... only creating the issue IF someone makes a comment.
Cheers!
Seeing...
First, for each blog post you plan to publish, create an issue in your blog's GitHub repository issue tracker. I'm assuming that's a by hand thing. I think someone needs to find a way to automate that.
ghpages-ghcomments is the automation you are seeking ;-)
And even better... only creating the issue IF someone makes a comment.
It sounds like you are worried about having lots of repo issues opened that don't have any reader comments. Or, do you mean something else when you say "only creating the issue IF someone makes a comment" would be better?
@wireddown What I mean by "automation" is that you don't have to "prepare" for comment by doing anything & no issues entities would be created unless somebody made a comment. So if you made 20 posts, and got 3 comments all on different posts, only 3 issues items would be created. And.. they would only be created "on the fly" as the comments were added.
Cheers!
Thanks for your sharing. Most articles I found with google tell me to use a third-party comment system which I would not like to follow. Yours is very brilliant. It is something like realizing a comment function on my own site.
hello. could u pls publish all the codes which ur blog post describes on ur github a/c? it's more convenient for users to use them to build a github issues based blog. tks very much
Seems this doesn't work anymore :( Checked with clean Firefox profile without uBlock:
This is because http://datejs.googlecode.com/svn/trunk/build/date-en-US.js no longer works (causing JS errors in the date parse, breaking all JavaScript in the page). Suggested alternative: https://cdnjs.cloudflare.com/ajax/libs/datejs/1.0/date.min.js
Thanks for catching that, @selivan and @NickCraver! :bow: :zap: I've updated the script link for that library so things should be back to normal. 🤞
great post :+1: I'm working on something similar at https://utteranc.es :crystal_ball:
This ist perfect... much thanks! With that comment system gets my blog more nerd style.
Just add a archor to the comment link -> #new_comment_field
www.github.com/izuzak/izuzak.github.com/issues/12/#new_comment_field
😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁😁
Thanks for your brilliant idea. During building my own Github-comments for my blog, I make my comment CSS style same with Github Issue style.
http://wingjay.com/2017/06/08/rebuild-personal-blog/
This is cool. Thanks for sharing. Exactly what I was looking for. Haven't read all the comments here (looks like it works so well you got a lot) but why not create a form on your page to capture comment input and then using github api to push that comment to the associated issue on github?
why not create a form on your page to capture comment input and then using github api to push that comment to the associated issue on github?
Take a look at https://github.com/wireddown/ghpages-ghcomments
😊
