3

I am busy writing a plugin with a free version and a paid, Pro version. For our initial release of both versions, I want to keep things as simple as possible, so I would rather defer using a strategy of a very extensible free version, with hooks implemented in a Pro version; I will give this direction some attention for later releases. My next avenue is to simply have two completely separate builds that include some core, shared components, and some components specific to the Pro or Free versions.

The purpose of my question here is to try and gather some advice on my third angle, that of using checks in code that only perform actions etc. if a certain version is running, i.e. if the client calling core services is Free or Pro. What should I be looking at to attempt this avenue of feature limiting?

Improve this question

2 Answers 2

Reset to default
2

You alluded to this in your comments, one way is to provide an API key for your plugin, that way your clients are actually paying for support and updates and not code, it's really one of the only decent ways to go about this. For example if their API key is not valid or expires they do not get access to your private forum or any plugin updates ( you would need of course to provide a API for a unique key, external update request and authentication).

Improve this answer
1
  • Hmm, I like the API key route, thanks. I will need to do some homework to implement it, but I like tools I have used with API keys, so this is definitely on the cards.
    – ProfK
    Commented Oct 30, 2011 at 10:09
2

Unless you encode your code, you can't protect a plugin that bundles both versions but works differently based on... settings. Maybe amateurs will consider this a roadblock but I'll hack it viciously in a couple of minutes and unlock everything (that'll never happen as I write all my plugins... just sayin').

Only way to do it is by encoding the plugin code with ionCube or another PHP encoder. But then, you're breaking the GPL License that is: Open Source-ish and enforces itself on plugins that work with WP... Salute and thank WP for this one!

So the combo version is ruled out by common sense and lack of encodability due licensing issues. You're left with two versions. Totally distinct or a PRO extending a BASIC but different package (distributions). Don't merge functionalities as you won't make a sale. And those that find out the PRO was there for the taking when they paid for it... will be mad :)

Maybe I'm wrong and WP users people are nice and like to buy Plugins. NOT!

Regards ;)

Improve this answer
2
  • Our target is business users, who actually do like to buy plugins. My goal is not to protect code, as, as you say, anybody with PHP in a Few Hours can remove protection, but our customers buy into very solid support services when they purchase a pro version.
    – ProfK
    Commented Oct 30, 2011 at 5:59
  • Good for you :) Don't combine! Create BASIC and extend PRO on it. Keeps basic lightweight and pro 'grounded' into basic. It's harder to maintain two different chunks of code doing things in common. And keeping basic fat-free is also a good thing. Why parse 3x code when only 1x will be used.
    – EarnestoDev
    Commented Oct 30, 2011 at 6:06

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.