gde_get_short_url() returning error message & numPages retrieval solution

  • 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!

    https://www.ads-software.com/extend/plugins/google-document-embedder/

Viewing 12 replies - 1 through 12 (of 12 total)

  • 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

    Thread Starter Dan Rossiter

    (@danrossiter)

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

    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

    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

    Version 2.5.4 | By Kevin Davis | Visit plugin site

    Re-installed it. Thanks. Problem solved.

    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.

    Thread Starter Dan Rossiter

    (@danrossiter)

    Kevin,

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

    -Dan

    Thread Starter Dan Rossiter

    (@danrossiter)

    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

    Thread Starter Dan Rossiter

    (@danrossiter)

    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

    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

    Thread Starter Dan Rossiter

    (@danrossiter)

    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

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘gde_get_short_url() returning error message & numPages retrieval solution’ is closed to new replies.