- Posted on
Wed Jul 11, 2018 3:54 am
-
DaveL17
offline
-
- Posts: 6781
- Joined: Aug 20, 2013
- Location: Chicago, IL, USA
-
It is extremely unlikely that the change in OS affected the plugin in this way, but rather more likely that the plugin got into a bad state when it was restarted. My production installation looks to be working as expected (although WU is taking a LONG time to respond to API calls). However, when I restarted my development environment, I saw the behavior you described. I disabled and re-enabled the plugin and normal operation resumed. I've looked at the changes between 7.0.10 and 7.0.11 and don't see anything that would have caused this behavior. I did find a typo in the setting of the initial plugin configuration DEFAULTS though, which will be fixed in the next version.
The plugin checks every 30 seconds to see if an update is called for. If an update is called for, it does its thing and updates the next scheduled poll value (the next scheduled poll value is displayed within the plugin configuration dialog). I'm guessing that the plugin got into a state where it was not updating this value properly such that it was always time for an update (the current time exceeded next poll time every 30 seconds). You can always see when the plugin thinks the next poll is due by examining this value in the plugin configuration dialog box.
The API call limit is "hard coded" into the plugin such that it is a user-defined number set within the plugin configuration dialog (the default value is 500). The WU API doesn't return the number of calls to it--a long sought feature that WU never implemented--so as a proxy, the plugin attempts to track this on the users' behalf to keep it from burning through your raindrops when things go sideways.
If and until I can find (and fix) whatever caused this bad state, I would suggest that the workaround is to disable and re-enable the plugin.
I came here to drink milk and kick ass....and I've just finished my milk.
[My Plugins] - [My Forums]