[wp-hackers] pluggable functions

Mon Oct 29 03:04:04 UTC 2012

I've been wondering about this for a while. WP_Dependencies (the class
extended by WP_Scripts and WP_Styles) seems well suited to handle some sort
of library load in the same way we can register, unregister
and prioritise scripts and styles.

---------------------
Daniel Dvorkin
Móvil: +54 (0261) 15-315-2244
Skype: mzaweb
http://mzaweb.com

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

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