Introducing the Kernl WordPress Statistics Page

On an average day Kernl handles around 2 million requests from 135,000 unique domains. Our analytics offering lets you use this data to make better product development decisions, but there is also a more holistic view of the Kernl and WordPress ecosystem to be had. I’d like to introduce to you the Kernl WordPress Statistics page!

What is it?

The statistics page gives you a high level overview of Kernl ecosystem. This is a subset of the overall WordPress ecosystem with the important distinction that every domain represented has paid for a plugin or theme. It includes information around WordPress versions, PHP versions, and the language that the site is in.

Kernl WordPress Statistic Image

 

API

There are a lot of neat visualizations that you could make with this data over time, so the API is exposed and can be used by anyone. Check out the Kernl API documentation to get started. No authentication required.

Awesome! Where do I go to see this in action?

Check out https://kernl.us/wordpress-installation-statistics , or go to the Kernl homepage and scroll all the way to the bottom.

What’s New With Kernl – April 2018

Welcome to April! It was fairly light month for Kernl feature-wise as we’ve been spending more of our efforts on marketing and advertising. We did manage to get a few things done, so lets get in to it!

Features & Bug Fixes

Plugin Update Icons – You can now set the icon that shows up in the WordPress update dashboard! No more gray power outlet icon! To set it, go to your plugin -> edit -> meta and then upload an image.

Multi-Subscription Bug – It was possible (although hard) to get your account into a state where you had multiple Kernl subscriptions assigned to it. This has been resolved. If you notice this happening to you on your invoice, please reach out to jack@kernl.us.

Upgrade to Node.js 8.10.0 – Kernl is now run on the latest LTS version of Node.js. Performance and security updates were part of the upgrade.

Envato License Check Bug – There were certain situations where the Envato license check functionality wasn’t working. This has been resolved.

Blog Post – A new blog post about how I develop features for Kernl.us

How I Develop Features for Kernl.us

A little over 2 years ago I started a tiny side project called Kernl to scratch an itch, solve a problem, and learn some new technologies. It has been successful beyond anything I could have imagined and I’ve learned a ton of new things along the way. One of those things is how to ship new features to customers quickly, safely, and with the commitment to stability and performance that my customers have come to expect.

The full process for developing features on Kernl touches a lot of different areas: Customer Support, Product Management, Software Development, and Marketing. It’s taken me some time to figure out a good process for all of these things, so I’m sharing my learnings in hope that it helps someone out.

Scale

Kernl isn’t that big. Honestly, it isn’t big at all compared to the likes of Facebook, Instagram, Google, etc. But Kernl isn’t small either. It’s just big enough that I have to worry about scale, availability, and consequences to the WordPress sites that it interacts with on a daily basis should it go down.

Kernl Scale Google Analytics Image

Remember how I said Kernl was a tiny side project when it started? Well it was developed that way too originally: A full-stack monolith on a single $5 DigitalOcean droplet. As time went on and Kernl grew I eventually split everything up and landed at a highly available setup that can scale horizontally, but I got some scars along the way. Those scars taught me two things:

  1. Your customers don’t care why you went down.
  2. Don’t take unnecessary risks.

With those two things in mind, I organically grew into a process that helps release features slowly, gather feedback from targeted customers, and then release it into the wild.

Customer First Development

Kernl has a backlog of about 200 items that should probably get developed in the future. There is a constant stream of new ideas that get added to backlog, sorted, and filed for later. But the one thing that always makes it to the very top of the backlog is a customer feature request.

Kernl Trello Board with Backlog

When a customer feature request comes in, the first thing I do is try to figure out what exactly it is they are requesting. Once I have an OK handle on that, I respond to the customer and explain what I think they are asking for. This helps me clarify the requirements and solidify my understanding of the feature.

Once I’ve got a handle on what they’re asking for I take a few moments and decide not only if I can implement this feature, but also if I should implement the feature. As I don’t yet work on Kernl full-time, the hour (or less!) that I spend working on it every night is precious. If I don’t think that the return on a feature is going to be high enough I often have to turn it down. Most of the time though feature requests are reasonable 4-5 hour projects and I’m happy to implement them.

Developing for Safety

I have an extremely low risk tolerance when it comes to Kernl. One of the things I like about Kernl is that I can leave it alone for a few days and be confident that it won’t have exploded while I’m gone. Every feature I develop for Kernl has the potential to ruin my confidence in it, so I’m very careful about how I do things.

The first step I take is to always create a feature branch. This may seem like a no-brainer to most software developers, but I have very unpleasant memories from 10 years ago before I realized how stupid it was to always develop directly on master. Once I have a branch created I get to work. If the code I’m writing is in one of the critical high traffic paths I’ll do proper TDD because it helps give me confidence that I’m not going to get woken up at 2am because of a coding mistake. If the code is not in the critical path I’ll generally write the tests afterwards or as I go along. The coverage is still good and meaningful, but development tends to be a bit quicker for me this way.

Once the feature is mostly complete, I wrap it in a feature flag so that I can easily toggle it on and off when I need to. If you aren’t familiar with feature flagging, its a process that allows you to decouple feature releases from code releases. For Kernl, I dogfood and use Kernl’s feature flag infrastructure to toggle features on specifically for the customer who requested it.

Kernl Feature Flag Overview

The Slow Release

As I mentioned above, using Kernl’s feature flagging I can be extremely choosey about who sees a new feature. The first thing that I do once I deploy a new feature is toggle it on for myself. After I’ve taken some time to test it out and verify the functionality I’ll toggle the feature on for the customer who requested it.

One of the great things about having developers as your main customer base is that they’re often very happy to help shake out features (especially when they requested it!). If the customer doesn’t find any bugs over the course of a few days and I’m satisfied that feature won’t cause any trouble, I change the feature toggle to a simple on/off toggle and leave it on for everyone.

The best part about this approach to development is that it gives me peace of mind. If I start getting notified in the middle of the night that the new feature I just released is acting up, I can just log in to Kernl, disable the feature flag, and go back to bed. Obviously this doesn’t work if the offending code is in the feature flag area, but most of the time its a non-issue.

Basic Marketing

As a developer it took me awhile to realize something about releasing new features: People won’t notice them unless you market them. After learning that hard lesson, every new feature that Kernl gets also receives a simple blog post, Twitter message, and marketing email. I personally believe that every new feature should be celebrated and I’ve found that generally customers are happy to see active development happening on a product that they’re paying for.

Sendgrid Marketing Campaigns

Kernl customers don’t log in to the product every day. Ideally they have WordPress continuous deployment set up so they only need log in to setup a new product, so chances of them noticing a new feature just by usage are small. Because of this usage pattern basic marketing is essential for existing Kernl customers so they know what’s new.

While this full process can seem a little bit heavy for a side-project, when you have a bunch of paying customers who rely on you for a critical piece of their product you have to be careful.

Kernl Now Supports Update Icons

Have you ever wished that Kernl supported plugin update icons? Well, your wish is our command!

Before

As you can see, before this change the icon displayed on the WordPress update dashboard for Kernl-based plugins was the default “power cord” image.

Kernl Plugin Update Icon - Before

After

Now you can upload your own icon to Kernl and have it displayed in the update dashboard.

Kernl Plugin Update Icon - After

Getting Started

Using the new plugin update icon feature is easy.

  1. Add the latest version of the plugin_update_check.php file to your plugin.
  2. Upload an icon (64×64) to Kernl in the plugin meta tab.

How to upload new plugin icon

That’s it! Deploy your update so that all of your customers get the new plugin_update_check file and Kernl will start serving your update icon when you release your next update.

If you have any questions or need help getting set up, shoot and email to jack@kernl.us

What’s New With Kernl – March 2018

Welcome to March everyone! Lots of great stuff happened with Kernl this month, so lets get into it.

Features

  • New Marketing Site – The new marketing website for Kernl launched! For most of Kernl’s life the marketing page has been a single landing page optimized for only plugin and theme updates. Since inception Kernl has grown to include a lot more than just updates and the new marketing site reflects that.
  • PHP Version and Install Language Analytics – Kernl Analytics can now track what PHP version your customers have installed as well as the written language of the site. Knowing this information can help you make smart data-driven decisions about internationalization and which programming language features you can target.
  • Plugin & Theme Dashboard Views – Previously when you went to the “versions” page in Kernl you were greeted with just a list of versions for the plugin/theme. Now you can easily see downloads stats, licenses, versions, and Git deployments in one easy screen.
  • Let’s Encrypt SSL Certificates – Kernl switched over to using Let’s Encrypt SSL certificates.

Bugs Fixes & Other

  • The /latest-version endpoint now includes the version id.
  • Build emails were not displaying the correct repository. This has been resolved.
  • Digital Ocean has been doing scheduled hard reboots of servers to handle Meltdown/Spectre issues. We’ve had to carefully manage this process but it looks like we made it through mostly unscathed.
  • There is now a simple proof-of-concept realtime channel on the marketing home page that updates the download count. Eventually we hope to use realtime with feature flags and any other number of things.

What’s New With Kernl – February 2018

This was a HUGE month for Kernl! We finally launched our initial analytics offering, fixed some bugs, and added some smaller customer request features. Let’s dive in!

Features

  • Analytics – Kernl now provides analytics for your plugins and themes! The first iteration of this feature allows you to see what domains your product is installed on, what product versions are installed, and what WordPress versions your product is running on. This can be very helpful for troubleshooting and justifying using newer WordPress features. You can check it out by going to the plugin/theme list page and then clicking the black “analytics” button.
  • Ephemeral Download Links – You can now create download links that expire after a period of time. This is useful if you don’t want your download link being shared. You can create these new short-lived links by going to version list of your plugin/theme and clicking “Download Link”. There is also an API available for programatic use.

Small Changes & Bug Fixes

  • More monitoring has been added to Kernl’s infrastructure using Digital Ocean’s monitoring offering.
  • Our Nginx load balancers / reverse proxy servers have been upgraded to have 1GB of RAM. Previously they both had 512MB.
  • When a new customer signs up for Kernl they are now automatically signed in.
  • Verified that Kernl works on WP Engine.
  • Added better error handling if your new version upload to Kernl fails. Prior to this it was possible for a new version to be created but not have a file attached to it.

Introducing Kernl Analytics

Have you ever wanted to know what version of WordPress your customer is running? Or perhaps what version of your plugin or theme? Maybe you have a plugin or theme that’s installed on hundreds or thousands of sites and you want to know which ones?  If you answered “yes” to any of these questions, Kernl Analytics is just what you’re looking for!

analytics product versions

Kernl Analytics gives you insights into how your customers are using your plugin or theme. If you’re an agency, Kernl analytics gives you quick insights into the websites that you manage. Using our domains feature you can see what domains your plugin or theme is installed on, as well as what WordPress version is installed. Looking for PHP version or what language the site is displayed in? That’s coming soon!

Kernl Analytics Domains

To enable Kernl analytics, go to the plugin or theme list in Kernl and click the black “Analytics” button. Because of the nature of gathering and storing this information at scale, Kernl Analytics is an add-on to your current Kernl subscription that costs $10 / month. The Kernl Analytics subscription also comes with a free 30 day trial so that you can try it. The Kernl Analytics subscription covers all of your plugins and themes regardless of how many you have or how many sites they’re installed on.

We’re super excited about providing WordPress plugin and theme analytics for you and hope you are too!

What’s New With Kernl – January 2018

Welcome to 2018! 2017 was a great year for Kernl and we’re excited to start 2018 out with some new features that you’ll find useful.

Coming Soon – Kernl Analytics!

An often requested feature for Kernl is some basic analytics around who’s using your product, what WordPress version they’re using, and the domains where it’s installed. It’s not quite ready yet, but we’ve already got some interesting data from January 2, 2018 to share while we finish up. When completed, you’ll have access to this data and more for all of your plugins and themes.

  • Requests processed – 1.58 million
  • Unique domains – 120,000
  • Top 5 WordPress versions:
    • 4.9.1 – 55,367
    • 4.8.4 – 27,151
    • 4.7.8 – 14,523
    • 4.6.9 – 4,748
    • 4.5.12 – 3,207

But enough with the analytics! Let’s talk about what’s new RIGHT NOW for Kernl.

Features & Bug Fixes

  • PDF Invoices – Have you ever wanted to download a copy of your Kernl invoice? You’re now able to do this for all of your recent invoices.
  • Feature Flag bug fixes – It somehow slipped past us that our feature flag API endpoints weren’t respecting account limits (max number of products or flags for your plan). This is fixed now and some useful warning dialogs were put in place for when you hit your max.
  • Blog – Last month we finally got a blog in place. This month we added Google Analytics to it, worked on SEO, picked a better theme, and wrote a few blog posts.
  • Expired Session Redirect Loop – There was a bug in the frontend Angular application that allowed a infinite redirect loop to happen. This has been resolved.
  • General Work on Kernl Analytics

That’s it for this month! Enjoy the new year!

Feature Flags – Managing a WordPress Beta Program

Let’s say that you’re an author of a premium (i.e. paid for) WordPress plugin or theme. You’ve been hard at work on an amazing new feature but it really needs some testing before it goes out to all of your customers. How do you manage this process? What’s the best way to get new code into the hands of your beta users with the least effort on your part? This blog post is going to walk you through the process of using Kernl Feature Flags to easily manage a beta program without having two separate builds of your product.

Table of contents

What is a feature flag and how does it work?

Feature flagging is a software best practice for controlling the release of features (sometimes called “gating”). Feature flagging is important because it allows you to turn features on/off without having to do a deploy. But how does this impact you? How does it make things easier?

Feature flags allow you to manage beta programs with a single version of your product. What most people currently do is have 2 version of their product at any given time: The live version (what everyone sees) and the beta version (what your beta users see).  Wouldn’t it be easier to just have one version, one deployment process, and highly granular control over who sees what features?

Feature Flags Product View

For example, in the image above you can see that I have two feature flags: “GitLab CI” and “Download Invoice”. Right now they are both active and people can see the features that they represent. If I decided to change “Download Invoice” to inactive, the feature would be immediately deactivated in my plugin. I wouldn’t have to do another deploy and release a new version to make it happen. It happens automatically in the code that’s already with your customers.

Seems great right? Let’s do a full example so you can truly appreciate the power of feature flags.

Example: Adding a feature flag to the Kernl Example Plugin

The Kernl Example Plugin is intentionally very simple. The goal of the plugin is to show off Kernl’s various features while not overwhelming the person who is looking at it. To illustrate how and why feature flags are awesome, let’s add a simple setting to the “Settings -> General” menu.

The example plugin currently looks like this:

<?php
/**
* Plugin Name: Kernl Example Plugin
* Plugin URI: https://kernl.us
* Description: The Kernl Plugin for testing.
* Version: 3.3.0
* Author: Jack Slingerland
* Author URI: http://re-cycledair.com
*/
require 'plugin_update_check.php';

$MyUpdateChecker = new PluginUpdateChecker_2_0 (
    'https://kernl.us/api/v1/updates/5544bd7e5b8ae0fc1fa5e7a5/',
    __FILE__,
    'kernl-example-plugin',
    1
);
?>
All it does is require “plugin_update_check.php” and instantiate the update checker. Let’s make things a little more complicated by adding a setting to the example plugin.

Add a setting to the plugin

// This is added below plugin update instantiation.

function feature_flagged_settings_api_init() {
   add_settings_section(
        'feature_flagged_setting_section',
        'Feature Flag Example Settings in General',
        'feature_flagged_setting_section_callback_function',
        'general'
    );
   add_settings_field(
        'feature_flag_setting_name',
        'My Feature Flag Setting',
        'feature_flag_setting_callback_function',
        'general',
        'feature_flagged_setting_section'
    );
   register_setting( 'reading', 'feature_flag_setting_name' );
}
add_action( 'admin_init', 'feature_flagged_settings_api_init' );

function feature_flagged_setting_section_callback_function() {
   echo '<p>This section is hidden completely behind a Kernl Feature Flag.</p>';
}

function feature_flag_setting_callback_function() {
    echo '<input name="feature_flag_setting_name" id="feature_flag_setting_name" type="checkbox" value="1" class="code" ' . checked( 1, get_option( 'feature_flag_setting_name' ), false ) . ' /> This checkbox is hidden behind a feature flag.';
}
 The above code simply uses the ‘admin_init’ hook to call the WordPress Settings API and add a menu item. It looks like this when you run the code:
Feature Flags Example Setting Image
 Awesome! We’re off to a great start. Now let’s wrap this in a feature flag so only our beta user’s can see it.

Create an On/Off feature flag

Kernl has extensive documentation for feature flag usage, but it all boils down to:

  1. Add the feature flag library to your plugin/theme.
  2. Create a feature flag product in Kernl. A good rule here is 1 plugin / theme to 1 feature flag product.
  3. Create a flag.
  4. Instantiate the feature flag library and wrap your code.
  5. Manage who see’s the feature using Kernl.

So let’s do step one. If you’re using Composer, follow the directions in the feature flag documentation. If not, you can go to https://github.com/wpkernl/WPFeatureFlags and download the WPFeatureFlags.php file and drop it into your plugin or theme.

<?php
// ... snip ...
require 'plugin_update_check.php';
require 'WPFeatureFlags.php';
// ... snip ...
Easy. Next, go to Kernl and add a new product in the Feature Flags section.
Feature Flags Add Product Button
When you click “Add Product” you’ll get to choose a product name. Since I’m using feature flags with my example plugin, I’ll name mine “Kernl Example Plugin”.
Feature Flags Add Product Modal
After you click save, you’ll see the new product at the bottom of your feature flag product list.
Feature Flags Created product in product list
Now here is something important! See the “key” next to your product’s name? You’ll need that to instantiate the WPFeatureFlags class. I’d go ahead and copy it to your clipboard now.
Next up, let’s add a simple feature flag for this new setting we’re adding. This is the thing that will control visibility for all of our users. Click “Manage Flags” in the product menu, and then click the “Add Flag” button. You’ll be presented with this screen.
Add / Edit Feature Flags screen
All the options look straight-forward, but let’s go over them anyways.
  • Active – Will this feature be toggled on or off for everyone.
  • Name – A descriptive name. I’m filling this in with “General Setting Checkbox Example”.
  • Identifier – This is how we identify the flag in code, so I like to make it short and easy to understand. I’ll be using “GENERAL_SETTINGS_CHECKBOX”.
  • Flag Type – Kernl has 3 different types of feature flags for your enjoyment.
    • On/Off – As expected, this toggles the feature on and off for every user. No granularity here, but super useful for quickly disabling things. We’ll be starting with this flag.
    • Individual – You can select specific users that a feature will be toggled on for. This is what we’ll be using eventually, but there are some caveats that come with it.
    • Percentage – Kernl will roll out your feature to a percentage of your user base. Nice if you don’t want to specify individual users, but also don’t want the feature turned on for everyone.

Edit feature flags example

When things are filled out, press save and get ready to move on.

Now that we have our feature flag created, let’s instantiate the WPFeatureFlag class and wrap our code.

<?php
/**
* Plugin Name: Kernl Example Plugin
* Plugin URI: https://kernl.us
* Description: The Kernl Plugin for testing.
* Version: 3.3.0
* Author: Jack Slingerland
* Author URI: http://re-cycledair.com
*/
require 'plugin_update_check.php';
require 'WPFeatureFlags.php';

$MyUpdateChecker = new PluginUpdateChecker_2_0 (
  'https://kernl.us/api/v1/updates/5544bd7e5b8ae0fc1fa5e7a5/',
  __FILE__,
  'kernl-example-plugin',
  1
);

// We add the feature flag code inside the init() function
// so that we can have access to who the current user is.
function feature_flagged_settings_api_init() {
  // The feature flag product key. Remember the key I said you should add to your clipboard? This is it.
  $kernlFeatureFlagProductKey = '5a24035ee48da05271310a71';

  // The user identifier is how Kernl identifies the user requesting flags.
  // This should be unique for every user.
  $current_user = wp_get_current_user();
  $user_login = $current_user->user_login;
  $site_url = get_site_url();
  $userIdentifier = "{$site_url} - {$user_login}";

  $kff = new kernl\WPFeatureFlags($kernlFeatureFlagProductKey, $userIdentifier);

  // This says "For the product defined above, does this flag exists, and if so, is it active for the given user?".
  if ($kff->active("GENERAL_SETTINGS_CHECKBOX")) {
    add_settings_section(
      'feature_flagged_setting_section',
      'Feature Flag Example Settings in General',
      'feature_flagged_setting_section_callback_function',
      'general'
    );

    add_settings_field(
      'feature_flag_setting_name',
      'My Feature Flag Setting',
      'feature_flag_setting_callback_function',
      'general',
      'feature_flagged_setting_section'
    );

    register_setting( 'reading', 'feature_flag_setting_name' );
  }
}

add_action( 'admin_init', 'feature_flagged_settings_api_init' );

function feature_flagged_setting_section_callback_function() {
  echo'<p>This section is hidden completely behind a Kernl Feature Flag.</p>';
}

function feature_flag_setting_callback_function() {
  echo'<input name="feature_flag_setting_name" id="feature_flag_setting_name" type="checkbox" value="1" class="code" '.checked( 1, get_option( 'feature_flag_setting_name' ), false ) .' /> This checkbox is hidden behind a feature flag.';
}

?>
Now that we have the feature flag in our code, let’s talk about some of the optimizations the WPFeatureFlag library has. One of the nice things about WordPress and PHP is that the code itself is stateless. Meaning that without some storage mechanism (MySQL, Redis, Memcache) the entire page and all of it’s data is rebuilt from scratch on every request. This is great for fast development cycles but not always for performance.
The WPFeatureFlag library helps with performance by storing flags for a given user as a WordPress transient for 5 minutes. This way repeated page requests by a user don’t constantly call Kernl and introduce network latency on the request. Kernl’s feature flag API is heavily cached but it’s better for the end user if flags are served out of your own store. What this means for you is that your user’s won’t see changes for a maximum of 5 minutes when you toggle a flag on/off. This is usually fine, but if you need shorter or longer intervals you can use the API directly.
That being said, go ahead and toggle the feature flag off in Kernl. In 5 minutes (or less) you’ll see the setting disappear from the admin. No code deploy needed. “That’s great!” you say, but what about beta program management? Easy. Let’s change this flag to an “individual” flag.

Create an individually targeted feature flag

The video below show’s you how to create an individually targeted feature flag. It’s the same as the on/off flag, except that you get to pick which user’s see the feature. One caveat with this is that if Kernl hasn’t seen the user yet we can’t target them. Why? Because we don’t know how to identify a user that we haven’t seen. If you went to target an individual user without having identified them yet, you would need to register them manually.

Now that the flag is targeted at an individual, that selected person will be able to see the menu setting. This is a contrived example, but you can see how this can be easily expanded to running a beta program. The best part is that you don’t need to have multiple versions of your plugin/theme out there. You can simply release one version, and toggle on features for specific people. In the future Kernl will support making groups of users so managing beta programs will be even easier!

If you have questions feel free to drop them in the comments!

Further Reading on Feature Flags

There’s a lot of great reading out there on feature flags and their uses. If you’re looking for more information about them, I highly recommend these resources.

What’s New With Kernl – December 2017

Happy December everyone! It’s been a busy month at Kernl. We’ve got a few great new features completed, some infrastructure updates, and a few bug fixes. Let’s get started.

Features

  • Customer Management – With the release of our new License Management product we introduced the concept of “customers”. As one would expect, a customer is someone who you assign a license to. The reason we introduced this was so that you could have multiple licenses associated to a single person and easily manage those from a single place. This is a huge improvement over the previous iteration and I highly recommend that you check it out. Hop over to the “License Management’ page and then click “Manage Customers”.
  • Customer Management API – In addition to the new customer management area in the app you can now access the customer management API. There are a lot of different ways that people purchase your plugins and themes so exposing a rich API is the best way to allow integration with Kernl. If you’d like to learn more, check out the documentation.
  • Purchase Code Migration – If you are a user of the legacy “purchase code” system you can now migrate all of your existing purchase codes over to the new license management system. When you go to the license management page there is a big call-out at the top when you can migrate your purchase codes. If you do this, make sure to update your plugin_update_check or theme_update_check file and where you instantiate the Kernl update class. Documentation for using the new license management system can be found here.
  • License Domain Restrictions – You can now restrict updates that are secured by license management to specific domains.

Minor Features & Bug Fixes

  • The web app has been upgraded from Angular 1.3.x to Angular 1.6.6. This is one of the first steps in a migration path forward to the next generation of Angular and a web app UI refresh.
  • You are now able to refresh the Git repository list that Kernl has with the press of a button. Before you had to disconnect/re-connect the integration.
  • In the interest of moving quickly, the first pass of license management and customer management did not have any tests written for it. This month we added a suite of tests around both APIs so that they remain stable.
  • Our back end application servers have been upgraded to Node.js 8.9.1. This brings security updates as well as new language features.
  • The license management documentation was updated to include links to the WordPress Settings API documentation. Kernl doesn’t make any assumptions about how your plugin or theme is developed, but people often ask what the easiest way to get licenses into their app is. The WordPress Settings API is likely the easiest, so it’s now mentioned in the documentation.
  • Meta tags have been added to the marketing site so that shares to Twitter look richer.
  • There was a bug in feature flags where individually targeted flags did not toggle on/off correctly.
  • All packages on all servers have been updated with the latest security fixes.

That’s all for this month! Have a great holiday season everyone!