I want to create a WordPress plug-in but also want to ensure that the plugin can only be used after it has been activated with a serial key that should be unique for each domain.

What is the best way to go about it assuming:

  1. I have to give the actual source code to the users and cannot have a VideoPress type of security - which is just a JavaScript wrapper for the actual content that comes from the plugin's server.
  2. I want to ensure that a novice to average PHP developer will not be able to cirumvent the security easily.
  • I'd consider asking this at Stack Overflow, as the core of your question is about creating a secure license verification system, rather than something specific to WordPress.
    – nobody
    Commented Aug 11, 2010 at 20:40
  • I just did that at: stackoverflow.com/questions/3462701/…. I will update the answers here in case I get something better there! Commented Aug 11, 2010 at 20:50
  • It might help if we knew what your plug-in did ... Does it process data? Add a UI feature? Syndicate RSS content? Knowing the function of the plug-in will help inform what possibilities exist for securing it ...
    – EAMann
    Commented Aug 11, 2010 at 21:12
  • @EAMann: I assume that this will fall under the 'process data' type of a system. I was more interested in trying to understand the mechanisms the current premium plugins that require activation use. The couple that I bought has pretty lax security to the extent where I was wondering about why did they bother even trying to put the activation feature in. Commented Aug 13, 2010 at 2:32

3 Answers 3


Option 1 - Process some data on your system

I wouldn't place all of the plug-in's processing on your own server, but pick one or two vital functions and keep them hosted on your system. Then require an API key for each site that uses the plug-in so that they can communicate with your server.

Option 2 - Encrypt stored data and require a hosted decryption key

Another alternative is a basic encryption setup - this is actually a system I've been toying with for a while, I just haven't bothered to deploy it anywhere yet. The code itself (to stay true to the GPL) is all plaintext just like you'd expect. However, all stored data (default values, plug-in settings, etc) is encrypted before being saved to the database. The trick here is that the plug-in on the remote system doesn't have the decryption key - in order to decrypt the data, it has to post its API key to your system which then responds with the decryption key. This can then be stored in a transient (temporary option) for a certain period of time before being flushed - that way you don't have a site hitting your server every 2 seconds during heavy traffic.

The downsides of this approach might outweigh the benefits, though (which is why I haven't deployed it anywhere yet). First of all, a savvy programmer can capture the decryption key and then they don't need your server any more. Or they could just flush out all the encryption/decryption hooks and run in plaintext. This is the advantage of open source for the user and the disadvantage to the developer who wants to distribute a free-but-restricted system.

The other downside is the dependency on your server. Storing a key in a transient lifts some of the burden off your server ... but if your site goes down for an hour or two, then every site using your plug-in goes down for an hour or two unless you plan for some kind of graceful deactivation. Also, it would mean you'd have to keep said server up-and-running indefinitely if people continue using your system.

Option 3 - Limit the features of the "free" version

A last option, and one I'm actively working on using, is to split your plug-in's featureset and functionality. The core of the system (UI, basic features, etc) is freely available without registration. For more advanced features, users have to register their copy, gain an activation key, then enter that key into the UI to complete the process - the plug-in then verifies with your server and downloads additional premium "add-ons" to the system.

The disadvantage here is that once downloaded, all the code now rests on the user's site and, under the GPL, they can still redistribute the full package. The advantage is that it only depends on your system once and doesn't require any kind of long-term download/processing support.

Any way you decide to move forward, you're either going to be hit with maintaining some sort of external API on your server or providing the full source of the system to your users. If you keep some functionality on your system, you almost have to guarantee 100% uptime for it to be worth it. If you're going to provide the full source, there's no way (under the GPL) to prevent someone else from re-distributing your system.

  • is there any example code to doing so? I know there are some plugins that can do licensing part, but I prefer to create my own code.
    – Ari
    Commented Nov 10, 2013 at 9:49

The only way to have a distributed plugin that has a secure license which any halfway decent programmer can't hack is to run the plugin's main functionality on your own server, like Akismet. The user must send a request to your server which contains their license key. If the key checks out, execute the source code on your end and send the results back.

  • That's what I was afraid of - and, that's the route I can't really take since the plugin that I am trying to author is pretty data intensive. Commented Aug 13, 2010 at 2:33

You can't hide the sourcecode away from WordPress users nor are you permitted to limit the redistribution of your plugin because of licensing implications.

You're creating a WordPress derivate with your plugin and your users have the right to get the source of it and to freely redistribute it (see the four freedoms in free software).

Assuming WordPress is licensed under GPLv2 and you have got non-US customers you should deal with implications of a GPL violance you might have in your ("protected") product.

You're trying to implement a vendor lock-in for your users.

  • This is all true, to the best of my knowledge.
    – user66
    Commented Sep 5, 2010 at 12:37
  • Well, VideoPress (created by Automattic themselves) does not give you any of the code it uses in the WordPress plugin. The WordPress plugin is just a javascript call to their server to process the request and get and serve proper data. Commented Sep 15, 2010 at 6:15
  • Continuing - If they can do it, so I am pretty sure it is legal. I understand that you cannot hide the source-code or not allow people to redistribute it. Again, this is only valid for the PHP code - the JS and CSS that you create does not come under GPL unless you yourself put it under that. So, effectively you can always just tell your users that they can redistribute all the PHP in your plugin as they like - but, the JS and CSS can not be redistributed (see Thesis license for more). Commented Sep 15, 2010 at 6:18
  • From the top of my head, there is some source code released even for the server part of VideoPress. But anyway you refer to a network service which is used by a plugin then. Like making a request to the google search engine for a term. Naturally such a plugin wouldn't deliver the sourcecode for the google search but only on how to invoke it. I see a difference beween the actual plugin and a remote service.
    – hakre
    Commented Sep 15, 2010 at 7:43
  • @Milo: How should that work? Law does not construe facts, even if you condense it into cases. However in one jurisdiction I know about that has case law - the US - you can find some GPL cases. And about derivates: It's written in the legal code there. I think the law is even called "copyright" in these old books already. Most likely at least the legal code nor the existing cases count as opinion in your eyes I guess, right?
    – hakre
    Commented Feb 19, 2015 at 7:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.