You might want to consider AuthO the plugin. It might function better for everyone if you did that.
It is kinda of aggravating to have someone tell you that since it works for them they aren’t going to take the time figure out what the problem is. Especially since this does not seem to be an isolated occurrence. Maybe you should just withdraw the plugin if you are not committed to correcting the problem, JMHO.
Good luck and take care,
Diane
Thanks for the OAuth suggestion. I have considered it, but it’s definitely non-trivial and I don’t really know PHP (the WordPress language) that well, so it’s a can of worms I don’t want to open. I expect it would just lead to even more bug reports since then the OAuth implementation might not work properly. I always tend towards “don’t fix it if it ain’t broken”, and if it’s broken only for two or three out of 600 users, that doesn’t count as broken.
That said, I of course understand your frustration when things don’t work. 🙂 But let me correct you on two points:
1. Withdrawing the plugin would be very sad for the 600+ users who are currently using it and don’t have a problem.
2. I always take time – some time – to try to figure out what the problem is, but if I can’t reproduce the problem and almost all of the users seem to be doing fine, the most reasonable explanation is that it’s caused by something local to the user having the problem. It’s entirely reasonable and normal in the open-source world to abandon issues that can’t be reproduced by the developers. The only time it’s reasonable to spend time and resources to really delve into a problem that the developer can’t reproduce and that less than a percent of users are reporting, is if the users are in fact paying customers (and furthermore, if the customers are financially important enough for you to justify the investment of resources you have to make to track down and fix the bug). And as I have made abundantly clear to bookishbug a couple of post up, I don’t have customers. 🙂
Take care, and I do of course hope it mysteriously starts working again.
One last question :). My website comes up as pfaeffle.com no http://www.pfaeffle.com would that make a different? I noticed that on all the sites that work that is how their sites show. Both mine and bookishbug do not have the www. Just a thought????
No, that should not be relevant at all. There are pages both with and without www that works, see for example http://runningoutofpages.com and my own blog https://www.relativisticramblings.com.
One last suggestion to both of you, @pfaefjourn and @bookishbug: Which PHP version are you using? If you have the possibility of changing the PHP version, does it work for some versions, not for others? If so, that would definitely be something I could investigate further. Remember to re-save the widget settings to reset the widget before each test.
-
This reply was modified 4 years, 8 months ago by
cmeeren.
Any progress on this? I noticed I’m seeing the same problem on my site too lately. I have a page with two GR Widgets, a “reading” shelf and a “read” shelf. One continues to work normally but the second has started showing “Error retrieving data from Goodreads. Retrying in 60 minutes.” Nothing has changed on my end in months other than the recent WordPress core update and GR plugin updates (same PHP version, Apache version, etc). I’ve tried removing and recreating the widget but no change. Maybe we’re limited to one GR widget per page now? Or there’s a limit API accesses?
@steevithak Could you give me your widget settings so I can test? (see the Troubleshooting section om the plugin page for what I need).
I’m using three widgets on my own blog with no problems, so there’s no hard limit. There is a limit to API accesses, but I’ll be very surprised if that’s surpassed.
It’s very interesting that you have one widget working fine and another not working. I’ve absolutely no idea why that would be. Are you using the same app key and user ID on both?
Also, note that sometimes the fetching can fail for whatever reason and work fine the next time. But if it’s consistently showing an error, then that’s not the case.
Btw, with the api key, make sure there’s no spaces at the start or end.
And finally, if you have caching plugins enabled, then depending on the settings, that might interfere with testing and cause the error message to be displayed even after its fixed (because the widget might be cached with the error message). So disable caching plugins while testing.
Hi, thanks for the offer to take a look. You can see my wordpress here: http://steevithak.com
The gr-progress widgets are in the right hand column.
Widget that’s working uses shelf name: currently-reading
GR: https://www.goodreads.com/review/list/50632260?shelf=currently-reading
Widget that recently stopped working uses shelf name: read
GR: https://www.goodreads.com/review/list/50632260?shelf=read
My Goodreads user ID: 50632260
I’d rather not post the API key in a public forum; anyway it hasn’t changed and has been working fine for months (and continues to work in one of the widgets).
I can confirm that the “read” shelf does not work for me either. Which means I can actually try to figure out what’s going wrong. 🙂 I think I already have a notion. Will investigate.
All right, I have fixed the problem in version 1.5.4 which should be up any minute now. @steevithak and @bookishbug, please take a look and see if it works.
Also be sure to read the new “Important performance considerations” part of the FAQ in the readme (on the plugin page).
Wow, that was fast! Yes, that fixed it for me. I read the FAQ. No worries if it’s taking a bit longer to load. I have the widget there to show what I’m reading and what I’ve recently read, so I understand that means the “already read” shelf is going to keep getting bigger and slower to load over time, even if I only display a few of the most recent ones. Maybe the slowdown is an indication that Goodreads need some kind caching or indexing on their end to speed up queries. Anyway, thanks for the quick fix!
Hmmm… would you advise increasing the widget cache time from 1 hour to 24 hours on large shelves so it’s not reloading as much?
Maybe the slowdown is an indication that Goodreads need some kind caching or indexing on their end to speed up queries.
Definitely. Sadly nothing I can do about that. 🙁
Hmmm… would you advise increasing the widget cache time from 1 hour to 24 hours on large shelves so it’s not reloading as much?
Absolutely. Do you really need 1 hour time resolution on your “read” shelf? 😉
Personally I use the cron job trick mentioned in the performance considerations, so I can update as often as I want without any impact to my users.
Oh, awesome, doing a cron job during the night would be ideal. I’ll take a look at that.
Do that 🙂 Personally I run one every hour 😀
