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

[David Anderson]

This is related but not the same as Dino's problem, but perhaps 
interesting to some.

I recently have been thinking about add-ons to plugins, because I 
launched some paid add-ons to a free plugin (updraftplus.com).

Not an easy problem. I eventually went for this route:

1) The free, fully functional plugin is in the WordPress.Org directory
2) If anyone buys a paid extension, then they have to manually install a 
second plugin (NOT from wordpress.org), which is the add-ons manager
3) The second plugin switches the original plugin to get updates from a 
new location
4) In the second plugin, they enter their username + password (from the 
shop website). This then connects them back to the store where they 
bought the extension from. Once they've done that, updates appear to the 
original plugin. Those updates contain a version of the original plugin 
which now includes their add-ons.

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. So the only difference between 
the wordpress.org free plugin, and the plugin with add-ons is a few 
extra files in that directory.

It was quite a lot of code to write, though that's partly because I had 
to also write the code fort he shop site to process purchases and to 
keep track of entitlements as they were bought and consumed.

David

> Hello list,
>
> given that last time I had a philosophical question about my plugin, I
> got great feedback from the list, here I am, again
>
> As my plugin WP SlimStat grows bigger and bigger, users request new
> features, options and new ways to display their stats. So I thought that
> it would be nice to follow WordPress' lead, and avoid implementing all
> of them in core, and instead work on ways to extend its functionality:
> child plugins (or add-ons, if you like). In order to avoid overcrowding
> the main Plugins screen, I was thinking about recreating a separate page
> within my plugin's options, where users can manage their add-ons for
> SlimStat, just like they do with regular plugins (delete, install,
> deactivate, etc).
>
> I've seen other plugins out there using the concept of 'child plugins'
> (where they have the API/Library/Core functionality and then a bunch of
> plugins relying on it), so I believe this idea of separating the
> maintenance and keeping the main Plugins area clean and well organized,
> is compliant with the direction WordPress is taking with version 2.6.
>
> So my question is: would it make sense to recreate such a 'sub'
> management page. If yes, is there an easy way to do it (include
> wp-admin/plugins.php ?) without having to reinvent the wheel?
>
> Thank you,
> Dino.


-- 
WordShell - WordPress fast from the CLI - www.wordshell.net