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

[Marko Heijnen]

Hey David,

Thats seems weird to me. I have the same plan for a plugin and I'm writing the add-ons right now. I don't need to touch the free plugin on WordPress.org since it has the right filters already.
When you need to change the main plugin to enable paid extensions then your main plugin is wrong coded. In your case you don't even need to manipulate the main plugin.

I could however understand that you would have a main paid plugin that takes care username+password and the updates for the extension.

Marko

Op 16 feb. 2013, om 20:26 heeft David Anderson <david at wordshell.net> het volgende geschreven:

> 
> 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
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers