-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added an noscript fallback for browsers without javascript enabled. #7
Conversation
This is excellent!!! |
else | ||
uri = "https://gist.githubusercontent.com/#{gist_id}/raw/#{filename}" | ||
end | ||
code = open(uri).read.chomp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if I'm offline? (Or if I don't get a 200)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing that out, I will fix that in the next couple of days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok! This is a great improvement and I'm excited to have it. Let me know if you need anything from me to get this done. 😃
So I added error handling. The user won't notice it when the raw code could not be fetched and the noscript-Tag will not be rendered in that case. I thought about even not rendering the script-Tag but I guess that would be kinda stupid, cause it might be possible that raw.githubusercontent.com is down and the javascript-Service isn't. 😄 |
Truth! Thoughts on a warning message? |
I am conflicted about a warning, cause it could confuse users and I don't rank the importance of that noscript tag that high that it deserves an own warning if you know what I mean. On the other hand I'd like to be warned when my site is build incompletely. (I wouldn't have implemented that feature if it wouldn't have been important to me to have the noscript tag in my rss feed.) So I am opting in on an warning message shown in advanced user mode. 😉 |
As long as the warning is crafted as such and doesn't change the exit code of the process, I think most users will be fine with it and will understand that it's not going to ruin their site. And hopefully they will be able to see that too. Jekyll.logger.warn "Warning:", "The <noscript> tag for your gist #{gist_id} could not be generated. This will affect users who do not have JavaScript available or enabled in their browsers." ? |
So what's your suggestion for that message? I am not that good at writing warning messages, I guess. |
@gr4y See my comment. |
…d when the response is an 404 an HTTPError will be raised. Rescue both of them now.
Hi @parkr, I just want to check if I can help you with anything to get that PR merged. Please drop me a line if there's anything that I can help you with regarding my code. 😄 |
I am so sorry, but I completely forgot about that until now. I just pushed the change into my fork. 😁 |
uri = "https://gist.githubusercontent.com/#{gist_id}/raw" | ||
else | ||
uri = "https://gist.githubusercontent.com/#{gist_id}/raw/#{filename}" | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about
uri = "https://gist.githubusercontent.com/#{gist_id}/raw"
url = "#{uri}/#{filename}" unless filename.empty?
to replace the if
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it does look cleaner.
I guess the same could be done for the gist_script_tag
method:
def gist_script_tag(gist_id, filename = nil)
url = "https://gist.github.com/#{gist_id}.js"
url = "#{url}?file=#{filename}" unless filename.empty?
"<script src=\"#{url}\"> </script>"
end
After a little while, I'm still not fully convinced on this one. I like the idea in theory, but if we have to download the raw content, why not just insert that? |
Don't get me wrong, but when one has to insert the raw content into the document one doesn't need the gist tag at all. It was absolutely frustrating for me to see posts in my rss reader where people talk about a code snippet and I couldn't see that code snippet without opening the post in my mobile browser. And I didn't want my readers to feel the same frustration I feel when I read posts in my rss reader. Sure I could have put the code snippets into the document itself, but what if I change the snippets later? With downloading the raw content from gist.github.com it will even update the code people see in rss readers or browsers with disabled javascript when I rebuild the page. |
👍 It’s too bad that the Gist embed code on GitHub’s end isn’t already built with progressive enhancement in mind. |
So I just wanted to read something in Pocket and I clicked on the post I wanted to read, scrolled down to the point where the code should be... And to my surprise the code snippets are completely missing. The Blog is hosted on GitHub Pages which still is using Jekyll 1, i assume? URL to the Post: http://nesv.github.io/golang/2014/02/25/worker-queues-in-go.html |
begin | ||
url = "https://gist.githubusercontent.com/#{gist_id}/raw" | ||
url = "#{url}/#{filename}" unless filename.empty? | ||
open(url).read.chomp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we use .strip
instead of .chomp
?
Ready to merge pending that one question above. |
As someone who now surfs the web without JavaScript enabled, this will be great to have. Thanks, @gr4y! |
The side effect: today I've updated my gems, and now any simple change in my local is generating a 30 seconds delay, due the all
|
Is it timing out? Can you paste the full error with --trace? |
Well... I thought about that some time ago and I know that it can be a problem on really bad internet connections and I came up with several ideas to solve that. Setting the timeout to 10 seconds, which should be quite okay for most of the people, but currently my internet connection is flaky from time to time, so it would result in generated posts with I even added some caching to the tag back in the days when I implemented that in my own fork and that might be the way to go, but I didn't like the thought of a changing the gists and upon the next build of the site the updated code won't be fetched because it is cached, which results in the gist and the actual I would love to hear your thoughts on that. I may take some time to respond, though. |
Making this optional might work. Could do that and enterprise host support in a 1.4.0 |
I thought about that too, but I am not a huge fan of adding more switches and toggles to any project. Being able to disable the feature would be okay, but I don't like it to be disabled by default. I don't know who to contact at GitHub to make them think about adding progressive enhancement to the gist embed code, but I think that should be the long term solution for everyone. |
Write support@github.com. They'll give you a canned response but it'll be on their radar then. I agree that we want this. I think a timeout of like 3 seconds is more than enough. 3 seconds for an API call is pretty absurd by any standard. If it is dropped, we should retry. |
I just looked into timeouts in Maybe using |
Definitely a Good Idea™. Ready to review a PR when you're rested! |
@parkr Thank you for the update. I'm just waiting to get it via |
@raelgc Try 1.3.2 |
This would be better for RSS readers and users with tinfoil hats and disabled javascript. It fetches the code via HTTP, escapes it and wraps into an noscript-Tag. To make the specs work again I had to add webmock to the development dependencies, so I had to update all specs and added new it-blocks to each context and an before-Block to stub the request. 💪
If there are any questions, don't hesitate to answer. I hope dearly that you will accept the PR, so all jekyll-gist users can profit from that change soon. 😄
Have a great day 🌞