Daniel

Milner

  • Home
  • Projects
  • Blog
  • About
  • Contact
  • React Component Library for Gutenberg

    React Component Library for Gutenberg

    I started playing with my website a few weeks ago and decided that I wanted to try moving the CMS back to WordPress and continue using Gatsby for the front-end. If I was going to use WordPress, I really wanted to use the Gutenberg block editor instead of the classic editor. After installing WPGraphQL and wp-graphql-gutenberg, I came to the conclusion that I needed to create components to display each block. So, I decided to create a component library that I could publish to NPM. Something I had never done before.

    The first blocks that I decided to support were the ones that this website uses. Headings, Paragraphs, Code, and Lists. Images were also just added since almost every site needs to display images. My plan is to work through adding support for the most common blocks first and working my way towards the more obscure blocks.

    The component library is on GitHub if you’d like to submit a pull request and on NPM if you’d like to use it in your project. Please mention me on Twitter if you’re using it. I’d love to take a look. Th

    • wp-block-components on GitHub
    • wp-block-components on NPM

    Daniel Milner

    August 26, 2019
    Uncategorized
    GitHub, NPM, React, WordPress, WPGraphQL
  • New Coat of Paint

    New Coat of Paint

    Update (7/29/2021): The site is now fully running on WordPress. Being a plugin developer, I wanted to be able to dog food my own plugins. I am leaving the post below for posterity.

    For the past several months, this site had been in a state of limbo. I had switched from WordPress to a barebones Gatsby v1 set up that used markdown files for each page, had no images, and didn’t contain any of my blog posts.

    About a week ago, I decided to update Gatsby to v2 and switch to a CMS for managing the data. Being a WordPress developer, I initially thought about using that to manage the data. But WordPress is a bit overkill for what I wanted. After a bit of research, I landed on Cockpit CMS. The biggest draw was that it was open source and has a beautifully designed UI.

    While I was at it, I decided to also give the site a proper redesign. So I fired up Figma and spent a couple of hours redesigning this site. Both Gatsby and Cockpit are such a pleasure to work with and I can’t wait to build another site on this stack.

    Here is a list of what I used to build this site:

    • Gatsby
    • React
    • CockPit
    • Netlify
    • Styled Components
    • Visual Studio Code
    • Figma

    Daniel Milner

    February 8, 2019
    Uncategorized
    Gatsby, WordPress
  • How to add limits to time-based prorated upgrades in Software Licensing for Easy Digital Downloads

    How to add limits to time-based prorated upgrades in Software Licensing for Easy Digital Downloads

    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;
    }

    Daniel Milner

    January 20, 2017
    Uncategorized
    WordPress
  • The WordPress Customizer and Checkboxes

    The WordPress Customizer and Checkboxes

    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

    Daniel Milner

    August 7, 2015
    Uncategorized
    WordPress
  • Fixing Mistakes

    Fixing Mistakes

    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.

    Daniel Milner

    January 15, 2015
    Uncategorized
    WordPress

© 2025 Daniel Milner. All Rights Reserved.

  • Threads
  • GitHub