Measuring the Performance of WordPress on DigitalOcean Droplets

Earlier this year Kernl launched our WordPress Load Testing offering. Prior to the launch we had been doing a series of blog posts testing the performance of “managed” WordPress providers. In this blog post I’ll test the performance of Digital Ocean’s VPS solutions with a standard LEMP (Linux Nginx MySQL PHP-FPM) installation by scaling it vertically.

Want to measure your own WordPress performance under heavy load? Sign up for Kernl.

Server & WordPress Configuration

The Digital Ocean 1-click LEMP install is already configured to take full advantage of as many cores and as much RAM as is available. During the course of these tests I never needed to tweak any server settings. That doesn’t mean that more performance couldn’t have been extracted through configuration tweaks, but even with these settings we were able to gain useful information about WordPress performance on the different Digital Ocean droplet levels.

With regards to WordPress configuration… there isn’t any. No caching, CDNs, or compression. Just raw WordPress. Its easy to get high performance out of WordPress if you cache everything, but seeing what performance looks like in the worst-case scenario is far more interesting.

The Test

For this series of tests I imported the contents of my personal blog (Re-cycledair) to the target and then used Kernl to run the load tests. Due to the nature of my blog this test is very read heavy. While this isn’t realistic for everyone, for my personal blog the test is representative of the actual traffic that it receives.

The test itself looked like:

  • Concurrent users – 500
  • Ramp up – 2 users per second
  • Duration – 30 minutes
  • Request Rate – Each user makes 1 request every second
  • Droplet location – New York City
  • Load test generator location – Amsterdam

Results

As expected the amount of traffic that we could handle scaled linearly with the amount of hardware we were using (and cost).

Cost -vs- Performance

One interesting thing you’ll see in the graph is that in two places the requests per second actually trend down.

Data

Looking at the data above you can see that I tried Digital Ocean’s standard droplets as well as their CPU optimized droplets. The difference between them is cost and dedicated hyper-threads. From a cost perspective, you’re better off going with the standard droplet in the same price category. Personally I expected the CPU optimized droplet to perform better, but this might not be the best type of workload for it.

What About Caching?

Just for fun I tried out the one-click install of WordPress with LiteSpeed configured on a $5 / month droplet.

Things went really really really well.

🔥🔥🔥🔥🔥

Thats right. By the time the test was completed my little $5 / month droplet was receiving 1800 requests / second WITH NO ERRORS. For perspective, thats 4.6 billion requests per month.

Conclusions

The data does a good job speaking for itself here, but in general you should definitely stick to Digital Ocean’s standard droplets when running WordPress. Even without caching you can get really good performance out of the $40/month droplet.

Want to measure your own WordPress performance under heavy load? Sign up for Kernl.

Load Testing the ChemiCloud Managed WordPress Hosting Service

At the beginning of December Kernl launched a closed beta for our WordPress Load Testing service. As part of the bug shakedown we’ve been spending some time load testing different managed WordPress hosting services. Some of previous tests include WordPress.com, CloudWays, and GoDaddy. For this test, we turned our sights on ChemiCloud.

How do we judge the platform?

Using Kernl’s load testing feature we run 3 different load tests against the target system.

  • The Baseline – This is a simple baseline load test that we use to verify that our configuration is correct and that the target can handle even minor traffic. It consists of 200 concurrent users, for 10 minutes, ramping up at 2 users / second, with traffic originating in San Francisco.
  • Sustained Traffic – The sustained traffic test mimics what traffic might look like for a read-heavy website with a lot of visitors. This load test consists of 2000 concurrent users, for 2 hours, ramping up at 2 users / second, with traffic originating from San Francisco.
  • Traffic Spike – This test is brutal. We use it mimic the sort of traffic that your WordPress site might experience if a link to it were shared by a Twitter or Instagram celebrity. The load test consists of 10,000 concurrent users, for 1 hour, ramping up at 10 users / second, with traffic originating from San Francisco.

All traffic for this test is generated out of Digital Ocean’s SFO2 data center.

What ChemiCloud plan was used?

ChemiCloud has several different tiers for managed WordPress hosting. We decided on the “Oxygen” plan. At a high level this seemed to align well with the hosting that we tested thus far.

ChemiCloud - Oxygen Plan
ChemiCloud – Oxygen Plan

Caveats

This load test is intentionally simple. It is read heavy. Many WordPress sites have this sort of traffic profile, but not all do. If you need to perform a WordPress load test with a different traffic profile Kernl supports this. Ideally we should also do multiple tests over time to make sure that this test wasn’t an outlier. Future load test articles will hopefully include this sort of rigor but for now this test can give you reasonable confidence in how you can expect ChemiCloud to perform under a read-heavy load.

The Baseline Test

200 concurrent users, 2 users / s ramp up, 10 minutes, SFO

As most of the hosting providers that we test do, ChemiCloud performed well on the baseline test. They settled in at right around 25 requests / second.

ChemiCloud - Requests
ChemiCloud – Requests

We did see a few failures towards the end of the test, but it appears that it was only a spike. Once the spike passed we didn’t see any more errors for the duration of the test.

ChemiCloud - Failures
ChemiCloud – Failures

The response time distribution for ChemiCloud was solid for this baseline test. 99% of requests finished in 550ms. If we go further down the distribution you can see that 95% of requests finished in ~250ms which is quite good. Even the 100% outlier still wasn’t that bad.

ChemiCloud - Response Time Distribution
ChemiCloud – Response Time Distribution

Sustained Traffic Test

2000 concurrent users, 2 users / s ramp up, 2 hours, SFO

For the sustained traffic test ChemiCloud did a great job serving requests while keeping response times down. As you can see from the graph below, the test settled in to right around 260 requests / second. The journey to that many users was smooth and there aren’t any surprises on the graph.

ChemiCloud - Requests
ChemiCloud – Requests

There were a few failures during the test period, but it appears that they were only a temporary blip. You can see that about half-way through the test we ran into ~32 failures. After that we didn’t see any more for awhile, and then we had one more before not seeing any again for the rest of the test. For some perspective, we performed 1,861,230 requests again ChemiCloud and only 33 failed. Thats a failure rate of 0.0017%! Nice work team ChemiCloud.

ChemiCloud - Failures
ChemiCloud – Failures

The response time distribution was pretty great for the sustained test as well. While there was an outlier at 100% (which is common), 99% of requests finished in under 400ms. Thats an effort worthy of praise with WordPress!

ChemiCloud - Response Time Distribution
ChemiCloud – Response Time Distribution

Traffic Spike Test

20000 concurrent users, 10 users / s ramp up, 1 hour, SFO

The traffic spike load test is brutal for any host. Nobody ever expects to see this kind of traffic out of nowhere so few are prepared for it. ChemiCloud handled the traffic rather well though. We eventually reached 1200 requests / second which is pretty impressive for a plan that costs $17.95 a month. There weren’t any surprises on the way up to that level of traffic, but as you’ll see we did start to see error rates increase.

ChemiCloud - Requests
ChemiCloud – Requests per Second

At about 15 minutes into the load test we started to see an uptick in failure rates. The rate of failure stayed consistent throughout the test after that. This is a fairly common pattern when hosts become overloaded with traffic. In general ChemiCloud performed well even with these failures. We sent 4,332,244 requests to ChemiCloud over an hour period and 134,893 failed. For this sort of load test a failure rate of 3.1% isn’t bad.

ChemiCloud - Failures
ChemiCloud – Failures

The most interesting graph from this load test was the response time distribution. You would expect to see a general degradation of response time performance as request failures increased but that wasn’t the case at all. Everything below the 99th percentile performed remarkably well considering the traffic we threw at it. 98% of requests finished in under 370ms. Great work!

ChemiCloud - Response Time Distribution
ChemiCloud – Response Time Distribution

Conclusions

ChemiCloud competes well with the other hosts that we’ve tested. They have a solid price-point and you get a lot of control over your WordPress environment. If you need a host that can handle some solid traffic spikes they are a good choice.

Want to be part of the Kernl WordPress Load Testing Beta? Sign up and then send an email to jack@kernl.us

What’s New With Kernl – November 2018

It has been a busy few months for Kernl. Lots of great work has gone into the WordPress load testing feature work as well as a few structural changes to increase reliability.

  • Cache moved to Redis – For as long as Kernl has existed our cache backend was powered by Memcached. We have now finished migrating to Redis hosted at Compose.io.
  • AngularJS Upgrade to 1.7.5 – Fairly straight-forward upgrade to Angular 1.7.5. We wanted to take advantage of performance improvements and few bug fixes.
  • WordPress Load Testing – Over the past few months we’ve been cooking up something new. Imagine if you could easily test performance changes to you or your client’s WordPress installation? Or be able to tell your client with confidence how many customers at a time their site can support (and what their experience will be like!). What if you could do all this without writing a single line of code or spinning up your own testing infrastructure? We’re ready to start beta testing so send an email to jack@kernl.us if you would like to be a part of it.

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!

What’s New With Kernl – November 2017

Happy November! The last month was all heads down on one new feature: License Management.

Features

  • WordPress License Management – As many of you know Kernl has had “Purchase Codes” for awhile now. It was clunky to use but generally very effective at it’s goal. License Management is the next generation of Kernl’s purchase code system. It’s less clunky, easier to understand, and doesn’t need to be tied to a plugin or theme. You can access it via the “License Management” button in the main menu. Pricing and usage limits can be viewed in the billing area.

What’s next?

Part of the new License Management system is the concept of customers. Ideally you should be able to tie multiple licenses to a single customer and manage them effectively through Kernl’s web interface or API. The new license management system was launched with a very simplified version of customer management, so the next month will be dedicated to making the customer management experience on Kernl amazing!

Introducing WordPress License Management with Kernl

For the past several years Kernl has been trusted with securing access to many people’s hard work via our license management system. We recently re-imagined our entire WordPress license management system, so we want to introduce it to you.

WordPress License Management

If you’ve ever sold a plugin or theme out on the open market, worrying about your plugin getting pirated is often at the top of your mind. One way to mitigate some of that risk is to use a license management solution. Kernl’s new license management system allows you to restrict access to your plugin or theme by forcing customers to activate before functionality is enabled. We can also check license codes before updates to your plugin or theme are downloaded, allowing you to restrict how many free upgrades a customer receives.

To summarize:

  • Kernl allows you to manage license keys for your product.
  • Kernl will restrict the number of updates a license is allowed to download for your product.
  • Kernl has a REST API that can allow you to restrict usage of your plugin until a license has been activated.

License Management Example

So how might you use Kernl’s WordPress license management? An example will illustrate this best.

The example above has a function to validate if a user’s license is valid. This can be used anywhere in your code to expose functionality only if the Kernl license is valid.

Restricting Update Downloads with WordPress License Management

If you would like to simply prevent your customers from downloading updates to your plugin or theme for free, just add the license parameter when you instantiate the Kernl update check class. This works the same for both plugins and themes.

The only difference between the sample above and a normal Kernl update instantiation is the inclusion of the ‘license’ property, which tells which license to try and validate with.

Going Forward

Want to give Kernl WordPress license management a try? Check out https://kernl.us and sign up. It’s free for 30 days and doesn’t require a credit card! In addition to license management and updates, we also have some great features like WordPress continuous deployment and feature flags.

What’s New With Kernl – October 2017

This month wasn’t a big feature month for Kernl, but there were some smaller bug fixes and infrastructure updates that are helping us serve our customers better. In addition to that, we also put out a short survey. Thanks to everyone who responded!

Changes & Bug Fixes

  • We are now able to automatically manage your BitBucket deploy keys. No more manually adding them!
  • Fixed & removed some flaky integration tests for feature flags.
  • Updated the documentation to reflect the BitBucket deploy key change.
  • Added some instrumentation around managing repository deploy keys and webhooks.
  • Upgraded application servers to Node.js 8.6.
  • A new cookie signature was deployed this month to fix a bug with authentication. You likely needed to re-authenticate because of it.
  • Upgraded all packages on our servers

Thats it for this month!

Private Premium Plugin Updates with Kernl.us

If you’ve ever created a plugin for WordPress and wanted to sell it you’ve likely run in to the problem of delivering updates to your customers. Agencies and internal developers run in to this problem as well.  You can’t upload your plugin to the WordPress.org repository because then it will be free for everyone, but you still really want integrated update functionality.

Kernl.us is a SaaS product that helps solve this problem (and so many others!). Kernl allows you to distribute updates to your premium plugin automatically using the built-in WordPress update functionality. So how does it work?

  1. Sign up for Kernl
  2. Create an entry for your plugin in Kernl
  3. Add 2 lines of code to your plugin.
  4. Upload your plugin to Kernl and then distribute it to your customers

Lets dive in an see how this works!

Creating a Plugin in Kernl

After you’ve signed up for Kernl, the first step to configure seamless automatic updates is to create a plugin entry in Kernl. To do so, click  the “Plugins” button in the left-hand menu.

Next, click the “Add Plugin” button.

The next step is easy. Just enter the name, slug, and description of your plugin then press “Save”.

Adding Kernl Update Code

Now that you have a plugin entry in Kernl, you can add the Kernl update code to your plugin. Download the Kernl plugin update code from https://kernl.us/static/php/plugin_update_check.php. and place it in the root directory of your plugin. Next, take note of the UUID of the plugin that you just created.

In your plugin’s main file, add the following code:

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

Replace “MyUuidFromKernl” with the UUID of the plugin you just created.

Uploading Your Plugin to Kernl

Now that you have Kernl inside of your plugin you need to zip it up. At the folder level, go ahead and zip the plugin using the zip tool of your choice.

If you were to extract your plugin, it should look like:

/my-plugin-slug
   plugin_update_check.php
   functions.php
   someOtherFile.php

If it looked like this (notice there is no nesting), Kernl will not work:

plugin_update_check.php
functions.php
someOtherFile.php

Take your plugin and click “Add Version” inside Kernl.

Next enter the version number (of the format MAJOR.MINOR.PATCH, ex 1.4.14), select the zip file you just created, and press “Save”.

Distribute Your Plugin

Now that Kernl has this version of your plugin, feel free to distribute this ZIP file to your customers. If you ever need to release an update, just make your code changes, zip them up, and upload the new version to Kernl. Within 30 seconds the update will be visible to your customers at which point they can download it!

What’s New With Kernl – July 2016

With summer in full-swing here in the United States, development on Kernl has been slowing down to accommodate much busier schedules than during the rest of the year.  This doesn’t mean we haven’t been busy though.

Features

Infrastructure, Bugs, and Miscellaneous

  • When the server throws a 500 error, it renders the correct template.  Prior to this fix Kernl would render a 404 page, which made it very hard to tell when you encountered an actual problem.
  • We now have a robots.txt file!
  • Kernl’s Mongo infrastructure has been moved to Compose.io.  Having a professional DBA manage Kernl’s database helps me sleep easier at night and provides customers with a more performant and stable backend.
  • The landing page for Kernl was taking over 1 second to load for many people.  Caching was added, and we now have the number down to under 100ms on average.

What’s next?

July is a busy month outside of Kernl, so I don’t expect much to get done.  The current plan is to take it easy in July and then come back with renewed vigor in August.