[wp-hackers] pluggable functions

[Mike Schinkel]

On Oct 28, 2012, at 10:03 PM, peter baylies <pbaylies at semperfiwebdesign.com> wrote:
> Mike, it's pretty easy to do version checking, of plugins or otherwise.

I'm not talking about libraries only used by one plugin/theme developer, I'm talking about PHP libraries (explicitly not plugins) that are designed to be shared by other plugins and themes, and even PHP libraries that are not specific to WordPress.  

For example, let's say I want to use one of the PHP libraries from GitHub[1] in my plugin.  How can I be sure that I can include it compatibly with other plugins?  There is currently no standard best practice for this so there is no way multiple developers can safely include it without potentially conflicting with other plugins that load it. The upshot is that few plugins or themes can readily build on shared code developed and maintained by others besides code that is shipped with core.

> As far as just the logic of it, wp_enqueue_script() handles this pretty well
> for Javascript / includes for the client, versions and dependencies.

wp_enqueue_script() is for files linked externally via HTTP. That's orthogonal to the loading of PHP libraries.

> For themes, add_theme_support() works well for managing specific named
> features.

add_theme_support() doesn't provide any method to negotiate multiple versions of the same external library. Yes, if only one developer includes includes their own libraries across multiple themes and/or plugins they developer they can manage it, but no developer can know how other arbitrary developers are managing the inclusion of the same library so there is no way for them to do it in a "best practices" compatible way.

> What kind of support would you want here for plugins?

Not sure how to explain it differently than repeating these two scenarios:


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."


> 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?

That's going back to the idea that plugins are a solution which, based on experience in the community I doubt they can be. Adding in the mechanisms that plugins would require has been suggested numerous times on this list and on trac in the past and too many people were against them for a variety of reasons. 

Besides plugins are very heavy what was is really just the need to ensure a potentially shared PHP library located in more than one plugin is not require()d more than once, and that the latest version is loaded and/or that a conflict can be gracefully identified.

-Mike

[1] https://github.com/languages/PHP

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