Bringing my WordPress plugins back with DoubleSharp Entitle

I wanted to resurrect some of my old WordPress plugins, polish them up, and create Free and Pro versions. The plugin work was only part of it. I also needed a way to sell the Pro versions, issue license keys, and get updates to the people who bought them.

The existing options weren't quite the combination I wanted: a headless service behind multiple front ends, usable from different frameworks and programming languages, with subscriptions and private updates included. WordPress was where I was starting, but I wanted to use the same system for other software too.

I built DoubleSharp Entitle to fit that workflow. It handles subscriptions, licenses, installations and private updates. Building it let me keep the licensing rules separate from the websites and choose how each application would get its updates.

Keeping the website separate

A product website and a licensing service have different jobs. I want to be able to change the website, use a different frontend framework, or give another product its own site while keeping the same licensing backend.

Entitle exposes its operations through an HTTP API. The included seller dashboard and customer portal use that backend, and custom front ends can use it too. Products and customers belong to a publisher workspace, so a publisher can manage several products together without mixing their data with another publisher's.

For payments, it supports Stripe-hosted Checkout and custom forms using Stripe Elements. A separate website can start guest checkout through its server and render an Elements form. Customer sign-in and account management still need the included portal or a complete same-origin session proxy.

That separation is useful to me even if I use the supplied interfaces at first. The website can evolve without moving the licensing system into the next framework I choose.

WordPress plugins and an Electron app managed in one Entitle demo workspace.

From a purchase to an update

I create a product, choose its framework, and configure a plan with an installation allowance. Paid plans use prices in my own Stripe account. Entitle checks the payment state with Stripe before granting access, then emails the customer a license key.

The customer enters that key in the plugin or application. The client activates a particular installation and receives a token scoped to that installation. Subsequent update checks and downloads use the token. Customers can manage their installations through the portal, including freeing a seat when they move to another site or device.

When I publish a release, Entitle validates the package and stores it in private S3-compatible storage. The installed client asks its update feed for a newer version, and Entitle checks whether that installation can download it. Once a version is published, its file can't be swapped out.

When a subscription expires, access to new downloads and updates stops. The installed version keeps working. The client adapters keep installed features independent of license status, so an expiration or a licensing-service outage leaves those features available. A customer can choose whether to renew without losing the version they already have.

There are also complimentary licenses with an expiration date and installation allowance. That lets me invite someone to try a Pro build before setting up paid sales. A complimentary license doesn't enroll them in a subscription.

License search, installation allowances and access status, shown with sample customers.

WordPress first, with room for other software

WordPress has a PHP adapter that connects licensing and private releases to its normal plugin update flow. The same backend has update adapters and examples for Joomla, Electron, Tauri, Sparkle and JetBrains plugins, plus a generic HTTP client.

Those clients use the update format their platform expects. Electron gets its updater metadata, Sparkle gets an appcast, and Tauri gets its updater JSON. Tauri and Sparkle signatures come from the publisher's build process; the signing keys stay there, and the installed updater verifies the signature.

The shared part is the customer, license, installation allowance and right to download. I can use PHP in a WordPress plugin, JavaScript in an Electron app, or Rust in a Tauri app without building another billing and licensing backend for each one.

Product-specific PHP configuration for a WordPress plugin in the demo workspace.

Why this fits my projects better

Easy Digital Downloads provides software licensing inside a WordPress store and exposes an API for other software. Freemius has APIs, checkout integrations and SDKs for applications beyond WordPress. Keygen offers API-based licensing with examples across languages. Those options cover parts of the workflow I wanted.

What makes Entitle a better fit for me is the combination: a backend I can run and modify, built-in Stripe subscription handling, customer self-service, and private updates in the formats my applications use. I can put different websites in front of it and keep the licensing rules in one place.

I made Entitle's source available so other publishers can run and modify it for their own software. It uses Elastic License 2.0 with an additional publisher-use permission, and the client adapters are MIT licensed. Self-hosting has no Entitle platform subscription or application fee; publishers cover their own infrastructure and provider costs.

I also plan to run Entitle as a SaaS service for other publishers. They'll be able to use the same licensing and update system while I manage the hosting and infrastructure.

Getting back to the plugins

Bringing the plugins back was the reason to build this. Entitle gives me the licensing and update system I wanted for that work, with room to use it for the next application too.

The Entitle Library page covers the setup and integration options. You can explore the product at entitle.doublesharp.com or read the source and documentation.