Imagine that you are a WordPress plugin author. Maybe you work for an agency or maybe you work for yourself. The point is that you have clients or customers that have come to expect a high level of quality from your work. Great job!
Now imagine that you have been working on a complicated but much sought after feature for your plugin. Complicated means risk. Complicated means that your hard-earned reputation for high-quality could on the chopping-block if you aren’t careful.

So what do you do? You need to release the feature but you also want to limit the risk you take by doing so. You can do few different things, but we’re here to talk about only one of them:
- “Dog-food” the new feature for as long as you can.
- Unit and integration tests can help test the validity of your code
- ⭐ Run a limited beta program with feature flags ⭐
Using Kernl Feature Flags to Manage a Beta Program
First of all, what is a feature flag anyway? A feature flag is a way of toggling sections of code on or off without doing a code deployment. At an extremely high level, it looks like this:
<?php
if ($flagActive) {
// enable feature
}
?>
Thats it. In practice implementing feature flags is a bit more difficult, but it doesn’t have to be much more complicated. For instance, using Kernl’s feature flag library:
<?php
$kff = new kernl\WPFeatureFlags($kernlFeatureFlagProductKey, $userIdentifier);
if ($kff->active('MY_FLAG')) {
// enable feature
}
?>
The beauty here is that you can toggle this block of code on or off for individual users, all users, or a percentage of users without ever needing to deploy anymore code.
And just like that ‘jack.slingerland@gmail.com’ gained access to the beta. No code deploys. No complicated anything. Just search, click, save. And what did this look like for the end user?
Before

After

Now this is obviously a contrived example, but it has all the building blocks you need to do far more complicated integrations.
A Beta Program
With the building blocks above you can see it isn’t hard to manage a beta program. Simply ship an update to your plugin wrapped in a feature flag. After that, add specific people to it as you see fit. As you get more feedback, continue to ship updates behind the flag. Once you are confident that the code looks good, you can remove the flag completely!
Now let’s dive in to the actual plugin code.
Tutorial
Adding feature flags to your plugin is a 3 step process.
- Create the product & flag in Kernl.
- Install the feature flag library via Composer
- Add the code to your plugin.
Step 1 is accomplished by signing up for Kernl and adding the product and flag. The product is just a container for all of your flags. That way your plugin can have a bunch of different flags in it but still be logically grouped together. For this case, let’s create a product called ‘Kernl Footer Flag Blog Post’ and a flag named ‘New Footer Beta’.
Step 2 is as simple as installing the Kernl WordPress feature flag library via Composer:
composer require kernl/wp-feature-flags
For step 3, you add some code to your plugin. Let’s take a look at it, followed by discussion of what it’s all doing.
<?php
require __DIR__ . '/vendor/autoload.php';
add_action('init', 'kernl_footer_flags_init');
function kernl_footer_flags_init() {
add_action('wp_footer', 'beta_program_footer');
}
function beta_program_footer() {
if (is_user_logged_in()) {
$currentUser = wp_get_current_user();
$userIdentifier = $currentUser->user_email;
} else {
$userIdentifier = 'Unauthenticated Users';
}
$kernlFeatureFlagProductKey = '5d835a2830cbb568728b9bd4';
$cacheTimeInMinutes = 1;
$defaultToActive = false;
$kff = new kernl\WPFeatureFlags(
$kernlFeatureFlagProductKey,
$userIdentifier,
$defaultToActive,
$cacheTimeInMinutes
);
if ($kff->active('NEW_FOOTER_BETA')):
?>
<style>
.kernl-footer-flag-bar {
background-color: #5d5d5d;
font-size: 12px;
text-align: right;
color: white;
}
</style>
<div class="kernl-footer-flag-bar">
You are in the Kernl Footer Flags beta program (<?= $userIdentifier ?>)
</div>
<?php endif;
}
?>
That’s the bulk of the plugin code (I excluded the Kernl updater for brevity). Let’s break it down.
Init Action and Composer Auto Load
require __DIR__ . '/vendor/autoload.php';
add_action('init', 'kernl_footer_flags_init');
function kernl_footer_flags_init() {
add_action('wp_footer', 'beta_program_footer');
}
In this code we auto load the composer dependency that we have. You can see it here. After that we define an ‘init’ action to add our beta program footer. The reason we have this in the ‘init’ action is because if we do it too early we won’t be able to fetch the current user (which we use to create a unique identifier).
User Identifier Creation
function beta_program_footer() {
if (is_user_logged_in()) {
$currentUser = wp_get_current_user();
$userIdentifier = $currentUser->user_email;
} else {
$userIdentifier = 'Unauthenticated Users';
}
After we define our action we create the function that it calls. The first thing we want to do is create a user identifier. The user identifier is used by Kernl to determine what feature flags that the identified user should see. In our case, if the person isn’t logged in they get lumped into an ‘Unauthenticated Users’ bucket. In the person is logged in, we identify them by their email. It is by this identifier that you will enable/disable features when using the ‘individual’ type feature flag. If we were using the ‘enable for a percentage of users’ type feature flag, simply assigning each user a unique identifier (maybe a UUID) would suffice.
Instantiate the Kernl Feature Flag Library
$kernlFeatureFlagProductKey = '5d835a2830cbb568728b9bd4';
$cacheTimeInMinutes = 1;
$defaultToActive = false;
$kff = new kernl\WPFeatureFlags(
$kernlFeatureFlagProductKey,
$userIdentifier,
$defaultToActive,
$cacheTimeInMinutes
);
The $kernlFeatureFlagProductKey is generated by Kernl when you create your product. The $cacheTimeInMinutes variable is so you can configure how long the flags will be cached in WordPress. If this is set to ‘0’, then the library will call Kernl every time the page loads. In general you probably don’t want this. And last but not least, $defaultToActive is a boolean variable. If true, the ‘active()` function will return true if Kernl can’t find a flag.

Active Check
if ($kff->active('NEW_FOOTER_BETA')):
The final piece is simply checking if this feature flag is active for this user.
Putting it all Together
If you want to see the source code for this plugin and/or install it yourself:
Conclusions
Kernl WordPress Feature flags are an incredibly powerful tool for safely releasing your code into the wild. In a situation like WordPress plugins where production is often not a machine that you are responsible for, being able to quickly toggle code on/off without a deploy is of paramount important.