[wp-hackers] pluggable functions

[Mike Schinkel]

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