Skip to content
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

Merged
merged 9 commits into from
Aug 5, 2015

Conversation

gr4y
Copy link
Contributor

@gr4y gr4y commented May 8, 2015

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 🌞

@parkr
Copy link
Member

parkr commented May 11, 2015

This is excellent!!!

else
uri = "https://gist.githubusercontent.com/#{gist_id}/raw/#{filename}"
end
code = open(uri).read.chomp
Copy link
Member

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)

Copy link
Contributor Author

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.

Copy link
Member

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. 😃

@gr4y
Copy link
Contributor Author

gr4y commented May 12, 2015

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. 😄

@parkr
Copy link
Member

parkr commented May 12, 2015

Truth! Thoughts on a warning message?

@gr4y
Copy link
Contributor Author

gr4y commented May 12, 2015

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. 😉

@parkr
Copy link
Member

parkr commented May 12, 2015

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."

?

@gr4y
Copy link
Contributor Author

gr4y commented May 12, 2015

So what's your suggestion for that message? I am not that good at writing warning messages, I guess.
"Could not fetch raw code of gist #{gist_id}" sounds a little bland.

@parkr
Copy link
Member

parkr commented May 12, 2015

@gr4y See my comment.

@gr4y
Copy link
Contributor Author

gr4y commented Jun 3, 2015

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. 😄

@gr4y
Copy link
Contributor Author

gr4y commented Jun 10, 2015

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
Copy link
Member

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?

Copy link
Contributor Author

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

@parkr
Copy link
Member

parkr commented Jul 26, 2015

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?

@gr4y
Copy link
Contributor Author

gr4y commented Jul 26, 2015

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.

@pathawks
Copy link
Member

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.

@gr4y
Copy link
Contributor Author

gr4y commented Aug 3, 2015

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.

screenshot 2015-08-03 19 51 34

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
Copy link
Member

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?

@parkr
Copy link
Member

parkr commented Aug 3, 2015

Ready to merge pending that one question above.

parkr added a commit that referenced this pull request Aug 5, 2015
@parkr parkr merged commit 730e45b into jekyll:master Aug 5, 2015
parkr added a commit that referenced this pull request Aug 5, 2015
@parkr
Copy link
Member

parkr commented Aug 5, 2015

As someone who now surfs the web without JavaScript enabled, this will be great to have. Thanks, @gr4y!

@raelgc
Copy link

raelgc commented Aug 6, 2015

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 gist usage in the site generating warnings.

Warning: The <noscript> tag for your gist xxxxx.

@parkr
Copy link
Member

parkr commented Aug 6, 2015

Is it timing out? Can you paste the full error with --trace?

@gr4y
Copy link
Contributor Author

gr4y commented Aug 6, 2015

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 noscript fallback code and some without, which is annoying too.

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 noscript fallback code in the post diverging.

I would love to hear your thoughts on that. I may take some time to respond, though.

@parkr
Copy link
Member

parkr commented Aug 6, 2015

Making this optional might work. Could do that and enterprise host support in a 1.4.0

@gr4y
Copy link
Contributor Author

gr4y commented Aug 6, 2015

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.

@parkr
Copy link
Member

parkr commented Aug 6, 2015

I don't know who to contact at GitHub

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.

@gr4y
Copy link
Contributor Author

gr4y commented Aug 6, 2015

I just looked into timeouts in OpenURI and found out that there is an read_timeout option. With Ruby 2.2 there is another open_timeout option, which is exactly the one we might need. But just passing it into OpenURI causes an exception, telling me that the option is not valid. (Geez, that smeels like some Java developers started to do Ruby... 😖) 😁

Maybe using NET::HTTP instead of OpenURI will do the trick, but my concentration is just fading away, so I will take another look at that later, when I am not tired.

@parkr
Copy link
Member

parkr commented Aug 6, 2015

Maybe using NET::HTTP instead of OpenURI will do the trick

Definitely a Good Idea™. Ready to review a PR when you're rested!

@parkr
Copy link
Member

parkr commented Aug 16, 2015

@raelgc Does v1.3.1 help?

@raelgc
Copy link

raelgc commented Aug 19, 2015

@parkr Thank you for the update. I'm just waiting to get it via bundle update. As soon as I get it, I'll update here :)

@parkr
Copy link
Member

parkr commented Aug 19, 2015

@parkr Thank you for the update. I'm just waiting to get it via bundle update. As soon as I get it, I'll update here :)

@raelgc We had to yank it because of #13. Fixing in #14 if you can help.

@parkr
Copy link
Member

parkr commented Aug 19, 2015

@raelgc Try 1.3.2

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants