Cause: a 3rd party web service (used to grab the location of a user) has been inaccessible lately, causing OIO to hang when running.
Solution: upgrade to v2.26. The standard upgrade procedure is to simply upload the new files over the top of the old ones. A step-by-step upgrade tutorial is also available here.
What it does: this update will stop OIO from hanging if 3rd party web services are inaccessible. It also adds the ability to turn off geo-targeting completely.
Please report any issues in the forum. As always, a full changelog is available by clicking here.
————-
Customised Installs: for those users who have template customisations, you shouldn’t need to over-write any of the templates. At the very least, you will need to overwrite the following files:
* the entire “admin” directory
* the entire “modules/demographics” directory
* the functions.php, install.php, upgrade.php files in the “include” directory
* all php files in the main OIO directory (eg. oiopub-direct/admin.php)
If you encounter any problems with updating the minimum number of files, you should try over-writing all files (in case you have an older install that requires a complete upgrade). You can leave the “templates” directory until last, since it is the least likely to require updating.
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.
This is the first 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.
Bad Behaviour is a plugin used by many security-conscious WordPress blog owners to restrict access to the blog. One of the ways it does that is to restrict calls from other websites, unless their IP address is whitelisted (ie. Bad Behaviour is told to let through traffic for that IP address).
By default, Bad Behaviour blocks calls from payment services like PayPal’s IPN, meaning OIO won’t get told when a valid payment has been made. This blocking applies to any automated payment notification, as well as calls by OIO itself (via the marketplace API key).
Luckily, Bad Behaviour comes with a whitelist file that we can use to add IP addresses, to prevent this blocking. I’ll use paypal in the example below, as it is the most common cause of complaint.
PayPal IPN Example
1.) Firstly, we need to find the IP addresses to add to our whitelist. PayPal provides a list of these here (other payment services will probably provide something similar). The IPN is governed by the IP addresses at notify.paypal.com, which at the time of writing are:
216.113.188.202
216.113.188.203
216.113.188.204
66.211.170.66
2.) Now we’ve got our list of IP addresses, it’s time to find the Bad Behaviour whitelist. There is a file within the plugin’s “bad-behaviour” directory called whitelist.inc.php. Open this file and you should see the following php code near the top:
$bb2_whitelist_ip_ranges = array(
“64.191.203.34″, // Digg whitelisted as of 2.0.12
“208.67.217.130″, // Digg whitelisted as of 2.0.12
“10.0.0.0/8″,
“172.16.0.0/12″,
“192.168.0.0/16″,
//”127.0.0.1″,
);
3.) Now let’s add the PayPal IPN addresses to that section of code, save the file, and we’re done:
$bb2_whitelist_ip_ranges = array(
“64.191.203.34″, // Digg whitelisted as of 2.0.12
“208.67.217.130″, // Digg whitelisted as of 2.0.12
“10.0.0.0/8″,
“172.16.0.0/12″,
“192.168.0.0/16″,
//”127.0.0.1″,
“216.113.188.202″,
“216.113.188.203″,
“216.113.188.204″,
“66.211.170.66″,
);
If you’re having problems with any other automated notification systems while using Bad Behaviour, simply repeat the process above using the IP addresses of that provider.
OIOpublisher IP Address
In case you’re also having problems authenticating your API key, you might want to add the IP address of OIOpublisher.com to the whitelist. At the time of writing, this is: 91.198.165.34
