No subject

something, while =91API=92 plugins just define a list of methods. Child plu=
gins
of =91parent=92 plugins would extend existing features, or build new ones u=
sing
the information managed by the =91parent=92. Taking WP SlimStat (analytics
plugin) as an example, it is a =91parent=92 plugin that offers a bunch of
features out of the box. Its =91children=92 could extend it by adding heatm=
aps,
or daily reports via email, or ways to export the data. They would use
the =91infrastructure=92 and the API available to do that.

Children plugin of =91API=92 plugins, on the other side, would CREATE new
functionality based on a common core: Twitter plugins (oauth) are just one
example, where the oauth part comes with the API, so that plugin devs don=
=92t
have to reinvent the wheel every time.

Some users contacted me off-list to offer support and give me feedback on
this topic. There=92s one phrase from one of the many tickets on Trac on th=
e
subject that I=92d like to quote here:

Dependencies help encourage devs to collaborate on common APIs that they
can all use for their own modules. ... Can you image how much repeated
code/effort has gone into the bajillion Twitter plugins currently in the
directory?

This is something that WordPress devs should really keep in mind: the
platform is great ALSO because thousands of plugin developers have decided
to actively contribute to the project by releasing their code, and by
donating their time and skills for a greater cause. Creating an environment
that encourages these people to collaborate and share portions of their
code can only benefit WordPress even more.

No doubt that all the efforts in improving revisions, post formats, UI etc,
that you guys are pouring into the development of 3.6 is priceless, but
plugin devs would like to get some love too, you know (at least from the
sense I get reading stuff around).

I understand that the implementation of dependencies would open a huge can
of worms ( http://core.trac.wordpress.org/ticket/22316 ), but we could
start working on a simple cosmetic change in the Plugins admin panel, where
plugins that declare their dependence on another plugin are grouped
together, and maybe listed under a =91collapsed=92 box or a separate
sub-tab =91add-ons=92 (next to all, active, inactive, drop-ins) or somethin=
g
like that.

This could be a good starting point, and make =91non-techies=92 happy, by
keeping the admin clean and not scaring people away with long flat lists of
plugins. To me (maybe because I=92m a techie) it looks more confusing the w=
ay
plugins are managed now.

Ciao,
Dino.


 *From:* Otto <otto at ottodestruct.com>
*Sent:* February 16, 2013 12:18 PM
*To:* wp-hackers at lists.automattic.com
*Subject:* Re: [wp-hackers] Child plugins (add-ons)

On Sat, Feb 16, 2013 at 11:03 AM, Kevinjohn Gallagher
<kevinjohngallagher at hotmail.com> wrote:
> Child plugins are absolutely the way forward.

I tried this idea, once upon a time. Everybody hated it. Users found
it confusing and difficult to manage. Many complained about having
many plugins instead of just one. Things like that. It's a good idea,
and I personally like it, but hey, I'm a techie and so are you.
Non-technical users hate it. Switching to an all-in-one approach with
checkboxes to turn parts on and off basically ended those support
messages.

-Otto
_______________________________________________
wp-hackers mailing list
wp-hackers at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-hackers