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.

What’s New With Kernl – June 2016

The past month of work on Kernl has seen a lot of great infrastructure improvements as well as a few customer facing features that I’m pretty excited about.

Customer Facing Features

  • Direct Uploads to AWS S3 – When Kernl was originally created all file uploads were stored directly on Kernl’s servers.  As we grew, this became an unsustainable solution, so the process changed to just use Kernl’s servers as temporary holding space before putting the file on S3.  This month we made this process even better by having files upload directly to S3. For you, this means faster uploads and less time waiting to get updates out to your customers.
  • Expiring Purchase Codes – You can now create purchase codes that expire on a specific date.  This allows you to sell your updates over time, instead of having to give them away for free for the life of the plugin or theme.
  • Max Download Purchase Code Flag – You can configure a purchase code to only allow a certain number of update downloads.  This will help resolve any issues with customers sharing purchase codes amongst themselves or across multiple installations.
  • JS Cache Busting – As customer facing features get rolled out Kernl automatically busts the client-side javascript cache for https://kernl.us.  This should help prevent confusion and remove the need for any sort of “hard refresh” when new features are released.
  • plugin_update_check.php Bug Fixes – There was an edge-case bug where some code in this file would collide with an old version of WP-Updates plugin update check file.  This happens when a customer has your plugin and also has a really old version of somebody else’s plugin installed.  This update takes care of that collision permanently.
  • Client-side JS Errors – A few minor miscellaneous bug fixes were performed on the front-end of Kernl.

Infrastructure

  • MongoDB – The month started off with Kernl’s database moving to it’s own server.  This was a temporary step that aimed to make the move to a highly available setup easier.
  • Mongo Replica Sets – After the first MongoDB move, the next step was to make the setup highly available.  Kernl now has 3 Mongo databases (1 master + 2 replicas).  In the event that the master database goes down, Kernl automatically fails over to one of the replicas with no downtime.
  • Memcache – Memcache was moved to it’s own server to make it easier to increase the number of items that Kernl caches over time.  This piece of the setup doesn’t need to be highly available.  If for some reason it goes down, Kernl will continue to operate fine.
  • Nginx – Nginx is used by Kernl both as a front-door to the application as well as load balancer between the app servers.  This was moved to it’s own server which allows it scale up when we need additional capacity.  In the future (hopefully soon), we’ll use a floating IP address to give this portion of the infrastructure the ability to fail over to a backup Nginx server.
  • Multiple App Servers – Kernl’s app servers can now scale horizontally.  We’re currently running 3 app servers which Nginx load balances traffic to.  This setup allows us to add app servers easily as our traffic grows.
  • Automated Deployment – Kernl can now be deployed with a single command.
    What’s Next?
  • Caching the repository list that you see when you set up CI builds.
  • Get a rich text editor set up on the installation and description fields.
  • Theme change logs.
  • Wrap up infrastructure work.
  • Sign in / Sign up with BitBucket & GitHub.
  • Slack Integration.
  • HipChat Integration.