License Key Deactivation Bug is WP Cron WP-CLI Known bug

Loading

For the last 2 years on and off we have had a small number of users who have a License Key Deactivation issue with their a3rev WordPress plugin License key. Try as we might we have not been able to find the cause. The a3rev Lifetime License key has many great features including

  • Full integration with WordPress plugins auto maintenance and feature upgrades
  • The ability to add additional sites to a Lifetime Key as an when required – 1 key for life
  • The key can be moved from site to site.
  • The ability to remotely manage Lifetime Key activations on all sites from the a3rev My Account dashboard

We could not count the hours that we and some of our customers have put into trying to resolve this issue over the last 2 years. Finally with the help of one of our switched on customers – Derek we have found the issue. You can read the support thread here

An overview of how the License key validation works on a WordPress site

When a plugin is activated by Validating the Key – a record of the domain name and IP address is created on the a3API

Each time wp-cron is run the plugin calls $_SERVER to get the Domain name and IP address from the server, the return is then sent to the a3API to verify the License and check for updates.

What we have been able to verify in the past is that sometimes this call instead of returning the domain name and IP address will return blank. The a3API then calls back to deactivate the key. This is a log of how that looked

Domain-and-ip

In the past we have always asked customers experiencing to problem to check why this would be happening. Finally with Derek’s host we found a engineer who was able to figure out why. Here is the reply he sent to Derek

After further investigation I noticed that the “SERVER_ADDR” is not being populated when ran from the command line using the PHP CLI, however it runs just fine when you ran it through a browser. So since I noticed that you have this cron set-up:

Code:
cd /home/xxxxx/public_html; php -q wp-cron.php
then it means WordPress automated events are going through the PHP CLI so the “SERVER_ADDR” is not being populated and you see from your log that when you update it manually the IP appears but when it runs automated through the cron PHP CLI it does not show the IP.

that means that WordPress wp-cron.php is being executed through PHP CLI, so the “SERVER_ADDR” is not being populated and you see from your logs that the IP is missing. However when you run the update manually (from your browser) the IP appears because “SERVER_ADDR” is being populated.

So in this case I could suggest you to change the cron command for the “wp-cron.php” execution, instead of executing it directly with PHP CLI you could use “wget” or “curl” to open through the URL.

WP CLI Bug

Now that we had a suspect we could do some more digging – it did not take long until we found that this is an open and known issue on the wp-cli Git – wp doesn’t fully populate $_SERVER array and here.

The Solution

The solution is to change wp-cron to a real cron job. Doing this have fixed the issue for Derek and for Oren on the support forum that was linked to above. This is actually good very good thing to do for your sites page load speed and performance.

You will perhaps not know that wp_cron is not actually a Cron job, but a “virtual Cron job” that fires everytime that a page is loaded. Every-time  someone opens a page you site, wp_cron is fired during page load It checks the database to see if there is any scheduled action to take.

There are two major issues with this:

  • Loading wp_cron during every page load negatively affects your site speed (and if there is a scheduled action to take, an unlucky visitor may have to wait before the page actually shows).
  • If you don’t get visits during a given period, any scheduled actions will not be triggered (example BackupBuddy backups).

There is a very good video done by the folks of hostgator that walks you through the process of turning off the wp-cron and configurea real and proper cron job that suites your site.

A big thanks to all those customers who have worked with us over the last 2 years to resolve this issue.

Posted in :