This update again focuses on streamlining the AdRotate Professional experience and improves a number of things in the dashboard. But more importantly it fixes the date pickers end dates and localization. We’re reversing to the old system that uses dd-mm-yyyy instead of named months. Another important change is the update routine going forward. More below.
Scheduling and planning
An essential part of AdRotate Professional revolves around dates. A while ago someone suggested to change the datepickers dates to a slightly different format to make dates more easy to read. I thought this was smart and it made sense. So I made the change.
Turns out that it doesn’t work at all for non-english dates. A thing I didn’t account for. I tried to create a translation thingy so that if you enter a Swedish or German date (or whatever language) it would translate it to English and it would be fine. But that didn’t work out. So the only “real” solution was to go back to the previous system.
Version 5.6.3 tried to fix the dates, but the localization issue crept up right after its release… This fix is for real and actually works!
If end-dates end up wrong no matter what you enter, clear your browser cache so that the date picker script gets refreshed.
Updating AdRotate Professional is a good idea. Staying up-to-date with most plugins is never bad. Updates are important for your websites security. But often they also add new or improve current features.
So update at least a few times per year.
That said, in my efforts to make updates more visible and available to everyone with a license I re-did parts of the update code and integrated it better into WordPress using certain filters and using WordPress transients for once. This works… But unfortunately WordPress triggers that transient (a sort of cache from WP) on every pageload. Often multiple times. I’m not sure why, but extensive testing and going back and forth with some users trying to pinpoint the issue didn’t provide a decent solution.
The problem with this is that your website would send hundreds if not thousands of update requests per hour to my server. Over the last 3 or so months I recorded more than 100 million update requests, thousands per second. Much like a DDoS attack.
So ultimately I decided to once again redo the update code and create a different trigger.
No more crazy filters, transients and going the WordPress route. Instead, AdRotate Professional now uses wp-cron on its own schedule and inserts the result into the WordPress routine after the fact.
Visibly nothing changes, but in the background a lot works different. And most importantly, this should eliminate the millions of update requests.
Thanks WordPress for your lousy documentation and stupid filters…
Changes for AdRotate Professional 5.6.4
- [reversal] Date format (dd-mm-yyyy) for date pickers
- [new] Datepicker months can be numbers (01-12) or names (Jan-Dec)
- [new] Update data is cached for 6 hours and refreshed once a day
- [change] Update checker no longer relies on WordPress schedule
- [change] Update checker no longer uses transient filter
- [fix] WordPress sending millions of update checks for some users
- [fix] PHP Error when archiving adverts with no stats