[wp-hackers] Child plugins (add-ons) (Dino Termini)

[Otto]

On Sat, Feb 16, 2013 at 4:32 PM, Mike Schinkel <mike at newclarity.net> wrote:
> I now realize I should have been more clear what I was asking.  I was specifically interested in know what you meant about "without breaching wordpress.org rules on remote code" and what you did to stay within the rules?

What Marko was describing is very simple, actually. Take this function
as an example:

function plugin_do_something() {
// ... bunch of code here to do stuff ...
do_action('plugin_do_something');
}

Now, if he uses that as his free plugin, but then sells some other
plugin entirely as an add-on to the free plugin, then the paid code
can simply hook to the plugin_do_something action added by the free
plugin to do its work. Same goes for filters.

The basic idea here is the selling of additional functionality in the
form of an entirely separate plugin which merely uses available hooks
in the free plugin to get the job done. It either adds code at the
right spots to the free plugin, or it modified values from the free
plugin to do something entirely different.

An ecommerce plugin could be presenting a cart and a check-out button,
for example. An additional plugin (which isn't in the directory and
doesn't have to be free) could hook into that functionality to add
paypal support, or support for multiple carts, or whatever add-on code
you're selling.


See, David said this:
> To prevent me from maintaining multiple code-bases for the original plugin, internally I implemented that as a sub-directory from which any present .php files are require_once'd.

That implementation is kinda silly and overcomplicated. Instead of
having an "add-on manager", the add-on plugin can simply do whatever
changes need to be done. It doesn't need to change the main plugin to
include its files, including files is the basic definition of a plugin
in the first place.

Consider two plugins: a) Example-Free and b) Example-Add-on. The free
one is in the directory. The add-on one is not, and when it's
activated, it gets included by WordPress just fine. No need to make
Example-Free recognize its existence in any way at all, really. The
free plugin can remain perfectly as-is, and just *have* the necessary
action and filter hooks for the add-on plugin to use right in it.


> That also implies a question as to what the rules actually are? I haven't seen anything listed on any of these links:
>
> http://wordpress.org/extend/plugins/about/
> http://wordpress.org/extend/plugins/about/guidelines/
> http://wordpress.org/extend/plugins/about/faq/

Guideline 8: No sending executable code via third-party systems.
David's description of an "add-on manager" system that replaced the
free plugin with the paid version would not be allowed in the
directory.

However, as Marko pointed out, his scheme is too complex as well as
being completely unnecessary. The "base" plugin can easily be the free
one, not violate any guidelines of any sort, and still leave action
and filter hooks in it for the secondary, paid, add-ons to be sold
elsewhere (ie. not on wp.org). And as was pointed out earlier, it's
possible for a plugin to check for its own updates from anywhere.
Those add-on plugins can check for updates from wherever they're
hosted, while the free-base remains on wp.org.


-Otto