[wp-hackers] pluggable functions

[peter baylies]

Hi Ben and Mike,

Ben, one basic point I'm making here is that in the case of a plugin order
load conflict, a pluggable function will fail gracefully, whereas a
non-pluggable function will crash and burn. And conflicts can be detected,
and the user can be warned by a nicely formatted warning in a box instead
of by a white screen and/or a PHP error.

Mike, it's pretty easy to do version checking, of plugins or otherwise. As
far as just the logic of it, wp_enqueue_script() handles this pretty well
for Javascript / includes for the client, versions and dependencies. For
themes, add_theme_support() works well for managing specific named
features. What kind of support would you want here for plugins? Maybe a way
to designate in the plugin headers that a plugin implements some feature,
and a way for other plugins to say that they depend on or provide some
level of support for that feature?

Cheers,

 -- Peter

On Sun, Oct 28, 2012 at 9:27 PM, Mike Schinkel <mike at newclarity.net> wrote:

> Hi Ben,
>
> On Oct 28, 2012, at 8:24 PM, Ben Lobaugh <lists at lobaugh.net> wrote:
> > I am with Mike here. I do not understand your reasoning. The main issue
> behind pluggable functions is that they can only be redefined once. You say
> you could have a free/pro version, that is in itself not even a good
> example. You could have a plugin order load conflict. If free loads before
> pro then that function will take precedence over the pro version.
> >
> > Or back to the wp_mail() example, I have a couple plugins I use for
> clients that overload wp_mail(), however I cannot have all of those plugins
> running at the same time. Only one wp_mail() can run at a time, so the
> other plugins miss out and only the plugin that loaded first gets to
> control wp_mail().
>
> Veering slightly off-topic, your comments address something I'm struggling
> with right now.  I see a way to resolve the issues I'm having but it would
> require WordPress to embrace a new concept in core and knowing how hard it
> is to get new concepts considered I haven't proposed it on trac. But in a
> nutshell I think WordPress needs to support the concept of "code libraries"
> and it needs a library loader.
>
> In the past people have been presented plugins as the solution for when
> you need shared code, but plugins don't work for this because they exist in
> user-space and there is an entire series of issues that derive from that.
>  For plugins to be viable we'd need dependency management of plugins for
> plugins and themes, auto-downloading and activation for plugins, and the
> ability to hide plugins from users. Most (all?) of those topics have come
> up in the past but each time they've died on the vine, probably for very
> good reasons.
>
> OTOH there's still a need. We need the ability in a plugin or a theme to
> say:
>
>  "I need library named "ABCD" and I need at least version X.Y.Z. I have a
> copy in my source and here is the filepath and here is the version number
> of the library I have, but don't load mine if another plugin is using the
> library, load their newer version instead."
>
> Additionally we also need to be able to say:
>
> "I need library named "EFGH" and I need exactly version X.Y.Z. I have a
> copy in my source and here is the filepath of the library I have, but if
> some other plugin needs a different incompatible version let me know so
> that I can tell the user I cannot load."
>
> One issue this could partially address is the issue with themes defining
> custom post types.  If we had this a theme could include a library that
> defines the custom post type that theme vendors are more apt to available
> said libraries available on GitHub. Then if someone changes themes they
> could use a new theme that also uses the same library, add the library
> support on their own, and/or use a general purpose plugin to load that
> library for them.
>
> This could also encourage the community to build and share libraries of
> higher-level APIs that are not ready or appropriate for core but for which
> cannot be successfully adopted if packaged as a plugin (plugins that only
> add an API have just not proven successful; look at how few plugins there
> are that require other API-only plugins, especially across multiple
> developers.)
>
> It would take very little added code to WordPress core to support this,
> but a lot of others would have to agree we need this including core team
> members to get into core.  Any takers on this idea?  I'll be happy to write
> up on trac if there's interest from anyone on the core team.
>
> -Mike
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>