Tag Archives: fix

Duplication errors on busy sites using AdRotate

Recently while following the search words in my Site Analytics a bit I’ve noticed that there is a small influx of people searching for a particular error that may pop up for some users after using AdRotate for a longer period of time or when your site is particularly busy.

The error in question is a duplicate entry error for the statistics AdRotate keeps and essentially means that the database is “full”.
The solution is rather simple and can be applied from PHPMyAdmin to raise the capacity in only a few minutes.

I have discovered this problem a while ago based on feedback from some users and created detailed page for users to resolve it. Due to the nature of the Query you need to run I do *not* want this in the automated upgrade process. So you have to make the change yourself.

If you run into the error;

WordPress database error Duplicate entry '16777215' for key 'PRIMARY' for query INSERT INTO wp_adrotate_tracker (ipaddress,timer,bannerid,stat,useragent) VALUES ('xxx.xxx.xxx.xxx','1358187611','59','i','')

(or something very similar)
You can find this in your servers “error_log” file through your hosting providers dashboard.

Check out this page with more details and the few simple steps on how to resolve the issue for you.

If you need help with this, obviously contact me as soon as you can and I will help you sort this out quickly.

AdRotate 3.8.3.4 and AdRotate Pro 3.8.3.4

And before I pop off to bed -

Some people reported that group creation broke. Somehow the code to add the wrapper to the database got lost. I need a break I think, making stupid mistakes like that.

Anyway, this patch fixes it. Also to avoid future confusion and complaints from Automattic who suddenly feel I don’t follow their plugin guidelines or whatever. The link/credit thingy has been removed from the plugin.

Changelog:

  • [fix] Group creation and editing (pro)
  • [change] “I’m using AdRotate” removed from plugin to conform with guidelines

Get it! get it!

Free users – Your patch has been submitted for review. Automattic is very picky. This might take a while.
Pro users – You can download the update from your account right now.

AdRotate 3.7.3b3 now available

I’ve made some changes to the installer and upgrade script. But more importantly the schedules should now rely completely on WordPress times making ad selection and time restrictions more reliable.

This change in usage of time is a result of various reports that newly created adverts would not display. These changes likely resolve these issues but it needs to be tested on more websites than just my 3 servers to be sure.

Download here.

Temporary workaround for non-beta users!

The way AdRotate works is that this issue likely has been in existence since the very first version of AdRotate, 4 years ago, but never became really visible because the start and end dates were based on full days instead of  to-the-minute precision. Therefor downgrading to older versions will not actually resolve the issue but merely mask it.
Additionally; re-installing the same version, removing all ads and starting over will NOT solve the issue. A larger margin on start and end dates will temporarily make ads work. For instance, If you want an advert to start to display on July 25th, set the schedule for the 24th. While inaccurate, the advert will show on the 25th with an overlap to the 24th. Apply the same rule to the end date, except have it stop a day later than intended.

So what’s actually wrong then – Time is time, right?

You can skip the rest of this post as it only explains my findings and where i think the issue lies with the websites AdRotate is installed on.

Over the past days I’ve discovered that the server (Apache, Nginx, etc.), PHP and WordPress each use their own measure of time.
WordPress relies on PHP and your timezone settings from what I could find.
PHP relies on settings made by the admins and the reported time by the OS.
Apache (or whatever webserver you use) relies on the system clock or OS time.
A lot of links in a chain that shouldn’t be necessary at all. In my opinion everything should rely on the same source. Either a system clock or other central source. But that’s not important right now.

Important is that AdRotate uses WordPress features for certain time notations, for example the translation of month names and am/pm settings.
For other more invisible functions, such as ad selection, AdRotate relies on the PHP times using functions like mktime() (gmmktime()) and date(‘U’).

apparently these times differ in some cases causing the schedules to work unreliable for some people. Even when applying timezone rules vs. using WordPress’ current_time() function the dates can be off by several hours. Even if the system time, PHP time AND WordPress time are in the same timezone.

For example; My development server which stands right here next to me is off by 14 minutes even though ALL reported times throughout the entire machine are exactly the same as my iMac and an analog clock. Both machines are on the same physical desk and internet connection synchronizing to the same time servers. Using the same times and file sharing between the 2 DOES report the right time. This means that PHP is wrong somehow. WordPress is right and the OS is right too, as far as i can tell.

Over the past days I’ve been reading up on all this mumbo jumbo and found all this kind of confusing. Therefor I decided to drop using PHP and System time entirely and have WordPress figure that part out. This will require some trial and error and some rewriting of routines. But at least AdRotate will be in “sync” with WordPress so there can be no conflict there.

I think I’ve covered most of it in this beta3 and this should lead to a more reliable AdRotate where time makes sense again.

AdRotate 3.7rc3 – minor issue

It turns out the upgrade of rc3 has a small typo in the upgrade. New installs are not affected. Upgrades from any earlier version are.

To fix this run the following 2 queries in PHPMyAdmin:

ALTER TABLE `wp_adrotate_groups` ADD `page` LONGTEXT NOT NULL ,
ADD `page_loc` TINYINT( 1 ) NOT NULL DEFAULT ’0′

Make sure the columns are added in at the end of the table. Without these 2 columns creating new groups does not work. The typo has been corrected and RC4 will have the fix when it’s released.