In version 3.5 of the Software Licensing add-on for Easy Digital Downloads (EDD), they added support for time-based proration of license upgrades. This is great! I’ve been wanting this for a while now. I just wanted a little more control over how much the upgrade could be prorated.

I can understand offering a prorated discount after the first month or two of an initial purchase. Someone might purchase a 1-site/year license to play with, then decide a month later that they’d like to upgrade to a 5-site/year license to use on the rest of their sites. Let’s say that the 1-site license costs $20 and the 5-site license costs $50. So, the difference between the two licenses is $30. If the upgrade cost is prorated, then the cost to upgrade would go down by $2.50 every month. After one month in, it would cost $27.50; after two months in, it would cost $25. The price goes down each month until it’s time to renew.

The concept is great, but I wanted to be able to specify a maximum amount that the upgrade could be prorated. Let’s say that we want that amount to be 50% of the upgrade cost. So, once the upgrade prorated down to $15, that’s as low as it could go. For a 1-year license, the upgrade cost would go down every month…until the 6-month mark where it would stop of $15 (50%).

Luckily, the EDD team is top-notch and they already have filters in place to be able to accomplish this. I just had to add my filter. Ideally, you’ll want to place this code someplace where it won’t get overwritten during upgrades.

add_filter( 'edd_sl_get_time_based_pro_rated_upgrade_cost', 'my_prefix_edd_sl_time_based_prorate_limit', 10, 4 );
function my_prefix_edd_sl_time_based_prorate_limit( $prorated, $license_id, $old_price, $new_price ) {
	$price_difference = $new_price - $old_price;
	$protate_limit_percent = '50';
	$prorate_limit_price = round( ( $price_difference / 100 ) * $prorate_limit_percent );
	if ( $prorated < $prorate_limit_price ) {
		return round( $prorate_limit_price, edd_currency_decimal_filter() );
	}
	return $prorated;
}

While working with checkbox inputs in the Customizer, I discovered an inconsistency with the values that were being returned to my plugin using the get_option  function. Please note that WordPress saves checkbox values in the options table as either “1” or “” for checked and unchecked respectively. Below are some of the scenarios that I encountered.

Scenario #1

In the Customizer, the checkbox is initially unchecked and the value is “”. I check the checkbox, the page refreshes and shows a value of TRUE. I toggle the checkbox and the value changes from TRUE (for checked) and FALSE (for unchecked). I save the settings with the checkbox checked and exit the customizer. The value is now “1”.

Scenario #2

With a value of “1”, I enter the Customizer. The value changes to TRUE and the checkbox is already checked. I uncheck the checkbox and the value changes to “1”. I check the checkbox again and the value changes to TRUE. Both checked and unchecked values are TRUE and “1” respectively.

In these two scenarios, while in the Customizer, checked values are returned as either TRUE or “1” and unchecked values are returned as either FALSE, “”, or “1”. Because of that, it’s impossible to know for sure the true state of the checkbox.

Fortunately, I was able to create a workaround by using the sanitize_callback  property when adding the settings, like so:

$wp_customize->add_setting( 'my_setting', array(
    'type' => 'option',
    'transport' => 'refresh',
    'sanitize_callback' => 'my_customizer_sanitize_checkbox',
    'default' => '1',
) );

And here is the code for the callback:

function my_customizer_sanitize_checkbox( $input ) {
    if ( $input === true || $input === '1' ) {
        return '1';
    }
    return '';
}

After that, I had no more problems. Checked checkboxes were consistently “1” and unchecked checkboxes were consistently “”. I didn’t find much information when searching for this, so I hope that this information will be helpful to someone.

There appears to be a ticket in trac about this issue from two years ago: https://core.trac.wordpress.org/ticket/24528

A couple of months ago, I added some code to a plugin that I wrote to use wp_schedule_single_event() in order to schedule some background processes. These were to keep data up to date and to clear out expired data. I did some testing on a few sites and everything seemed to work great.

A couple of weeks later, I started to hear from customers that their sites were slow. My first reaction was to blame their host or the other plugins that they had installed. More and more customers were mentioning that the plugin seemed to make their site sluggish. The weirdest thing was that I wasn’t experiencing it on any of my sites…until a couple of days go. I was constantly receiving fatal errors that the memory had been exhausted. I inched the memory up further and further until it was over 400MB.

That’s when I discovered my problem. Almost all of those cron jobs that I had been scheduling were still in the system. They never completed. Not only did they never complete…they kept getting added. There were thousands of cron jobs attempting to run every time a page loaded. No wonder I was running out of memory!

That night I could not sleep. I sat up in bed for a couple of hours and after some research, came up with a way to clear out those cron jobs. I used _get_cron_array() to find and un-schedule the jobs I had created. Because the cron jobs were scheduled with arguments, I had to loop through each cron in that array to find the correct arguments to un-schedule them.

Immediately, my site was noticeably faster! Now I had to figure out why it was happening and how to prevent it. After a day of trial and error, I got to a point where everything was running smoothly. Cron jobs were running, then removing themselves from the schedule. Not only that, but my memory usage was staying really low. Yay!

Finally, I was able to release an update for my plugin with the fixes in place. I created a version upgrade routine that would run only once to clean up the mess. I even created a bug fix plugin that we made available for a couple of our customers who couldn’t even have our plugin active without it crashing their site. Run the bug fix plugin, then re-activate our plugin and install the update.

It was a big mess, but I feel a huge weight off my shoulders knowing that it’s been taken care of. Luckily, our customers have been very patient with us.