WordPress.org

Ready to get started?Download WordPress

Forums

Google Doc Embedder
gde_get_short_url() returning error message & numPages retrieval solution (13 posts)

  1. Dan Rossiter
    Member
    Posted 1 year ago #

    Hey Kevin,

    It appears that the URL shortener is returning error messages when called too regularly. If you add a clause in gde_get_short_url() to check whether body equals the error message value (I'm seeing this: Error: Rate limit exceeded - please wait 1 minute before shortening further URLs.). This value is ending up cached which in turn makes the document unloadable until plugin cache is purged.

    On a completely unrelated note, I posted a while back mentioning wanting to find the number of pages in a given document. I've since found a simple way to do it just adding three lines into gde_get_contents(). Inserting the following directly prior to return $result will sets $pages to total pages in document.

    $ptn = '/,numPages:(\d+),/';
    preg_match( $ptn, $result, $match );
    $pages = $match[1];

    The only added overhead would be the cost of preg, which shouldn't be much. Could also be further optimized by using strpos() instead, if desired.

    Obviously this isn't useful on its own, but may have potential for improving plugin functioning. Even if it can't directly be used for any plugin functions, just making this accessible to developers would be probably be useful (obviously in a cleaner way than this simple example).

    All the best!

    http://wordpress.org/extend/plugins/google-document-embedder/

  2. k3davis
    Member
    Plugin Author

    Posted 1 year ago #

    Dan,

    Thanks for the detailed report. I should be able to roll a fix for the first issue into the next update. For the moment I wonder if you can work around it by commenting out the is.gd service line and relying only on tinyurl. I haven't investigated the difference in terms of rate limiting but it's worth a try.

    On the second point, that's a great find - this will certainly be useful as I eventually want to implement some completely different viewer display options in the next major version and knowing the number of pages up front makes some I had shelved look feasible again. Thanks for your investigation and for passing the info back.

    Happy new year!

    Kevin

  3. Dan Rossiter
    Member
    Posted 1 year ago #

    Thanks for the speedy response, Kevin! Happy New Years to you also!

  4. NW12
    Member
    Posted 1 year ago #

    Could you please help me to solve this problem?
    Fatal error: Cannot redeclare gde_supported_types() (previously declared in /home/intranet/domains/intranet.cmcgroep.nl/public_html/wp-content/plugins/google-document-embedder/functions.php:39) in /home/intranet/domains/intranet.cmcgroep.nl/public_html/wp-content/plugins/google-document-embedder/functions.php on line 53

  5. k3davis
    Member
    Plugin Author

    Posted 1 year ago #

    NW12,

    What version are you using? Those messages and line numbers don't seem to correspond with the latest release version.

    You may wish to try a clean install (complete removal / install from repository).

    Kevin

  6. NW12
    Member
    Posted 1 year ago #

    Version 2.5.4 | By Kevin Davis | Visit plugin site

  7. NW12
    Member
    Posted 1 year ago #

    Re-installed it. Thanks. Problem solved.

  8. k3davis
    Member
    Plugin Author

    Posted 1 year ago #

    Dan,

    If you're still monitoring this thread, I'm wondering if you could test a patch for the "rate limit exceeded" issue you mentioned above. I decided not to check for the text value of the error as it may change, but to look for the http status code that is.gd returns in that case. In the case of failure, it attempts a tinyurl shortening instead.

    If possible please replace the gde_get_short_url() function in functions.php with the one found here. I never generate enough calls to trigger this error so your validation would be helpful.

    Thanks.

  9. Dan Rossiter
    Member
    Posted 1 year ago #

    Kevin,

    I'd be happy to test that out. I'll be back with you within the day.

    -Dan

  10. Dan Rossiter
    Member
    Posted 1 year ago #

    Hey Kevin,

    I've done some testing and unfortunately am unable to reproduce the response from either URL-shortening service. I tested with the function as-is and when I got no errors from is.gd I commented it out to force tinyurl, but that also didn't return any errors.

    The tests I ran were far more heavy on requests than anything I ran the day I first encountered the issue so either their algorithms for flood detection have been changed or it's based on factors beyond requests from an individual user (overall server load, maybe).

    In any event, your solution looks like it should theoretically prevent the issue in the future. The only thing I would suggest is testing for the code being *between* 200 & 299 (inclusive). There are some other valid responses that wouldn't be equal to 200. You could also run your gde_valid_link() on the body as an added check just in case the servers aren't sending headers properly to verify that whatever is returned is reasonable.

    Sorry I couldn't be of more help, but thanks so much for working on this solution!

    -Dan

  11. Dan Rossiter
    Member
    Posted 1 year ago #

    Actually, decided to get smart and automate the test.

    After triggered the flood detection I realized your test is checking $response['code'], which should be $response['response']['code']. Also, checking if the return is identical to 200 is failing (I believe the header value is a string). Changing the check to a simple != returns as desired. If you make those changes then you should correctly detect invalid returns.

    Also, in running a two hundred requests in a few seconds I got zero failures from tinyurl, while is.gd stopped responding after about 30. You might consider changing the order that those two are in the list (assuming there is not already a reason for the order they are currently in).

    All the best!
    -Dan

  12. k3davis
    Member
    Plugin Author

    Posted 1 year ago #

    Hi Dan,

    Thanks so much for your thorough testing! You gave a brilliant idea there to use the gde_valid_link() on the response body. I believe that actually spares me from needing to check the response code at all (which I see now is an int, and I was checking for a string).

    I switched to is.gd as primary in GDE 2.5 mainly because their API was better documented and the URL was a bit shorter; neither are very compelling reasons. I wonder though how often people will be shortening that many all at once in real practice.

    Thanks again - much appreciate the extra time you spent testing this.

    Kevin

  13. Dan Rossiter
    Member
    Posted 1 year ago #

    Awesome! Yeah, testing the URL is probably the most accurate way to test.

    With the responses, I would agree that no normal usage would result in that many hits, but the first time I generated the error I wasn't doing anything out of the ordinary. That said, with the fallback working now I completely agree that there is not a whole lot of benefit to switching 'em.

    Thanks for all the work you've put into this!!
    -Dan

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic