dflydev

I don’t know why that doesn’t show up on the extend site. How WordPress extend site works is kind of a mystery to me. :-/

As far as the username/password, if you are defining those correctly I don’t think you should see the rate limit stuff anymore. Does it give you the warning every time, or just the first time and then a blank gist after that?

Could you try moving the defines higher up in the file? (maybe to the top?) See if that makes a difference? I don’t think it should but it is worth a shot.

If that doesn’t work, could you try changing to the wrong username and password and tell me if that changes anything? I want to try and figure out whether it is related to the _USERNAME and _PASSWORD fields in any way. If you put the wrong username and password in you should (hopefully) get a different error.

Can you verify that the version of the plugin that is actually installed into your WordPress installation has the _USERNAME and _PASSWORD code?

Bumping is a good trick to try.

I’m hoping that with the most recent changes things will eventually stabilize. I’m no longer distributing a copy of embed.css as that was not really a good way to do things to begin with. It was not able to keep up with changes that GitHub was making and would occasionally cause problems if the HTML changed that required CSS updates but embed.css didn’t get the update.

I’m not sure how much more I can do at this point. I have the plugin no longer including rendered HTML. You will only ever get plain

code or you will be seeing exactly what GitHub is sending in its embed code.

Can you share your gist ID with me so I can try to see this in person and see if I can figure out what is wrong?

I removed support for directly dumping rendered HTML + a copy of embed.css into the stylesheet queue. So things should be working for you if you are seeing “this gist brought to you by…” because I think that only shows up now if you use the JavaScript embed.

Actually, I take it back. I just pushed an update. If you can try out version 0.11 it would be greatly appreciated.

This plugin now requires json_decode and it will default to showing the JavaScript representation. If EMBED_GISTHUB_INLINE_HTML is set to true it will be largely unstyled.

I’ve been able to install WordPress 3.5 and am able to replicate most of this from here. Unfortunately it looks like several things have changed including the fact that requesting a specific file appears to be broken.

I think that this is going to take some work to fix. I don’t know that I’ll be able to do it in the next few days.

If someone wants to jump in and take a crack at it, please fork my repository on GitHub and send me a pull request. Otherwise this will have to wait.

https://github.com/dflydev/embed-github-gist

I’m guessing it is falling back on the HTML version and not using the JSON version. Is it possible you don’t have json_decode available in your install, @bill Sullivan?

Additionally, I believe GitHub rolled out a new version of Gist in the last day or two. It is possible they changed their output in a way that made it less friendly to WordPress themes.

I’m not sure how wise it would be to do anything with the text wrapping. Even if you visit the gist in its raw form at https://gist.github.com/3861583 you’ll see that there is no text wrapping.

Thanks for the updated gist. I assume that that blog is running your patched version of this plugin?

Would you be interested in forking this project on GitHub and submitting this as a PR?

https://github.com/dflydev/embed-github-gist

I apologize for the late response. I don’t control the HTML or the stylesheets that actually come from GitHub. I’ve seen some cases in the past where the HTML looks wonky but I think it was just a bad push from GitHub and it cleared itself up over time. Have you noticed this has gotten better or is it still looking wonky?

I’m happy to accept patches. Please see:

https://github.com/dflydev/embed-github-gist

Here are my comments on your feature suggestions:

Compose a Gist without leaving WordPress

I’m less interested in this one. Mainly because the entire plugin more or less geared to referencing an existing Gist. It is simple and short and not complicated. People might have more reasons to ignore this plugin if it looks like it does too much and/or imposes a specific type of editing on the backend. I’m not saying I’ll block it outright, but I think that if there is another plugin that does this (the one you referenced) maybe tweaking that plugin a bit to better meet your needs would be a better way to go?

Remove the Gist branding below the code as an optional attribute in the shortcode

I think that this would be fine. Make this functionality opt-in, though, instead of opt-out. ??

I apologize for the delay on this but these changes have been merged (thanks to CaioProiete’s patch) and are included in version 0.8.

I’ll take a look into providing this type of functionality! Please ping me again in a week or so if I haven’t updated.

Are you using private gists? Or did gist change the way it does things and now does everything by way of https?