Purchase OIOpublisher now for just $47.

Take control of your ad space.

Click here to purchase

Subscribe   OIOpub Blog » Wordpress Conflicts » Article: OIO and WP-super-cache

OIO and WP-super-cache

Filed under: Wordpress Conflicts

This is the second post in a series that looks at potential problems that OIO can have with other well-known WordPress plugins. You can see the entire series here.

Yesterday I had a report of a problem with OIO, which turned out to be caused by wp-super-cache. The file caching meant that OIO stats tracking was being bypassed, since it is done using php by default.

Initially I was going to give my standard reply of “switch over to javascript ad output” (since it isn’t affected by caching plugins, whereas php output is). However, it isn’t a proper solution in my eyes since it means that anyone who uses WordPress, a caching plugin and OIO might run into a similar issue. That would mean having to give my standard answer again…

Finding another way

It seems that only stats tracking is affected by WordPress caching plugins for normal use, so I came up with a solution that would still work when using php ad output. The tracking module performs a check for the existence of wp-cache / wp-super-cache and if found, will use an image tag to record stats instead of doing it internally via php. This tag will be cached along with the rest of the page, and so will load even when caching is active.

Ironically, I used to use an image tag by default. However, it caused some server load problems (because it meant OIO had to be loaded twice on each page) and so I stopped using it (an unintended consquence there!). This intermediate solution gives us the best of both worlds, since an image tag will only be used if actually needed.

The latest version of the stats tracker that contains this change (2.07 at the time of writing) can be downloaded here.

Any other problems with caching?

The only other issue that can come up as a result of caching is a lack of ad rotation. If the page html is cached, the ads will remain static until the cache is cleared. If you really want ads to rotate on every page load, and use a WordPress caching plugin, you  will have to use javascript to show ads with OIO.

7 Comments so far

Emiliano | December 2, 2009

Thanks for posting on this. I’m really interested in your software and this is one of the issues I was worried about. One more to go and I’ll feel comfortable purchasing!

mark | January 21, 2010

Im glad I saw this as I have been having the same problem with wp-supercache and the rotation element. Is there anyway that you know of to configure WP-supercache such that it will ignore items from OIO? Also, is this an issue with all ad rotations, or just fillers? IE – is this going to affect paid ads? This is a potentially huge issue for me and loading the ads via javascript will hurt my already huge page load time. Please advise.

Simon | January 21, 2010

The cache will affect all ads, paid or otherwise – if something is cached as static html, it will stay that way until the cache is re-generated.

Javascript is the only option that’s guarenteed to let you rotate ads normally. You could try experimenting with the “dynamic” parts of wp-super-cache (see faqs link below, half way down the page), but it’s not something I have any knowledge about:

>> http://wordpress.org/extend/plugins/wp-super-cache/faq/

If you’re experiencing very long loading times even with a caching plugin installed, it may be worth considering whether you actually need it. Saving 0.5s by caching the html does little good if the page takes 10s to load due to the number of http requests being made.

mark | February 14, 2010

I have had module version (2.08) for some time now but it appears that the impressions count is quite off – more than 60% lower than actual. I am using supercache… Any ideas? I also am not certain now about the click tracking and have a large campaign that I am trying my best to make sure is successful for the advertiser this month. Please advise. Also, when I look at the source code of my pages, I am not seeing any imagetag. Thanks.

Simon | February 14, 2010

The tracking of clicks should be fine – you have to go through the go.php file to reach the website, so the click will be recorded (providing the user has a valid IP address, user-agent and isn’t a search engine).

As you have a mixture of javascript and php output, the fact that the tracker.php image isn’t displaying could account for the lower number of recorded impressions. I’d do the following to start with:

1.) Re-upload the tracker module in its entirity, clear the blog cache and re-check for the tracker.php image.

2.) If you aren’t going to be rotating any ads, switch them all back to php (although I assume zone 4 does require rotation, hence why it’s javascript).

3.) Remove the “surplus” output (eg. if you have a javascript zone, make sure you delete the php output function, not just comment it out).

If there’s no luck with the tracker.php image displaying still, send me across some FTP details via the contact form and I’ll investigate.

Kenneth | April 22, 2011

If you use the Javascript ad server code on a higher trafficked website, how efficient is the coding, esp. if you are serving Adsense ads?

Wondering if it can cope with a site of 1000 visitors a day… without pulling down the server hosting the adscript OIO.


Simon | April 22, 2011

The best advice I can give is to test it out and see what extra load it puts on the server.

Can it handle 1000+ visitors per day, yes. Can it handle it on the server you are using, I don’t know.

Leave a Comment

Name: (required)

Email: (required)