Tag Archives: explained

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.

About the new blocks

There seems to be some confusion as to what to do with the new blocks. Especially if your site looks wonky after the update.
This was expected of course. Thousands of people use blocks and suddenly it changes. No amount of blog posts with warnings was gonna change this.

I did write about it a few days ago. But I didn’t quite explain what to change when you adverts show up wrong.
I’ve been on the forums today answering posts and also received some emails. Most people were confused at first but quickly figured it out after a few pointers to adjust the sizes and such on blocks. But why is this needed and how do you *really* fix the problem?

Details details details!

So what’s changed, really? Thers is a new set of wrappers adding to the ‘old’ one. That wraps around each ad and one that wraps around the entire block. This in itself doesn’t mean too much. But what is important is that Blocks used to be a set amound of ads. You defined how many columns it should have and AdRotate bluntly injected a linebreak were required to give you the impression of a block.

This is no longer the case. A block now needs to know the size of the ads. The thickness of the margins, borders and padding and the sum of it all determines the ad size. Which in turn sets the block size. All this uses a set of div tags that create an actual grid. Not unlike a spreadsheet.

How to configure?

The block needs to make a grid so it needs to know how many rows and columns it will have. Set a padding and/or border if you want.
You define the size of the banners and set a margin or padding if you want. Also here a border is possible.

One important cave-at is that if you use a border or padding on the individual ads these add to the ad size. So if you have a 125px banner a 2px border and a 3px padding. The ad-size will be 130px. A margin goes around the ad expanding to the outside and thus will not add pixels to the actual ad. But it will make the total block larger. You need to account for this when reserving space in your sidebar or page but AdRotate will calculate the size automatically for you.

Migrating existing blocks

Because AdRotate did not know what ads you showed in the old system and just went with whatever was offered there was no way for me to determine the size of ads. Assuming that many people used blocks to show button banners I set a default of 125*125 adverts with a tiny margin of 1px and no border. Obviously not everyone uses these settings and they will have to edit the blocks to suit their needs. This means defining the proper ad sizes and perhaps a border or margin.

Because there was no definition of rows in the old system I migrated over as much as I could and also for rows made an assumption based on the amount of ads you had using a simple sum. If your block was to show 10 ads in 2 columns that meant you had 5 rows. This value is used to determine the new grid size. However, the sum and resulting grid is not always correct because it’s an assumption.

This means that everyone using blocks needs to check the settings and very likely needs to alter a few things to make it work again.

Why screw up the old wrapper function?

It’s not screwed up, Nor is it a bug. It’s expanded into a better system. The old system inserted an ugly linebreak where a new row would start. The new system is more strict and uses valid CSS and HTML code to achieve a better looking result.

More on blocks can be found in the all new manual.