[wp-hackers] Facebook API and WordPress Plugin Development - Insight / Best Practice

[Mike Schinkel]

On Nov 14, 2012, at 4:09 PM, Otto <otto at ottodestruct.com> wrote:
> If you want background updating and the like, use Mark Jaquith's TLC
> Transient code:
> https://github.com/markjaquith/WP-TLC-Transients


Ironic that you referenced that today as I started working with it last night. :)

That library presents a great example of an issue I've been wrestling with lately which I described in a comment on this trac ticket:

http://core.trac.wordpress.org/ticket/22316#comment:28

Specifically let's say I build a plugin for distribution via wordpress.org and I decide to include Mark's library. Also Jeffrey Nolte builds a plugin and uses Mark's library too.  All is still good because Mark's library checks class_exists() before creating the class.

However, Mark has 3 pull requests and from reading those pull requests is seems like they have features that in some cases might be requirements for use. And those pull requests also modify the API. 

https://github.com/markjaquith/WP-TLC-Transients/pulls

So let's assume that Mark gets around to accepting some of these pull requests and publishes a new version of WP-TLC-Transients.

Now let's assume that Jeffrey really needs one of those new features so he uses the newer version WP-TLC-Transients. And let's assume my plugin was built with the older version WP-TLC-Transients.  And further, let's assume that somebody is using both of our plugins and that mine loads first so that the new version of WP-TLC-Transients doesn't load.  Jeffrey's plugin will crash is a manner that's hard for him to protect against and all because my plugin inadvertently broke his.  This is bad for the user, bad for Jeffrey because he has to deal with low value and time consuming support issues, and it's bad for me because my plugin inadvertently caused the problem.

The tragedy is that there is no current best practice to guard against this problem AFAIK. I have been wracking my brain for a solution that wouldn't require core to offer some sort of "traffic cop" features and I have come up with nothing. The only solution I can think of is to fork Mark's code and rename all the methods, but that is a really sorry state of affairs as it encourages fragmentation of code with various incompatible enhancements instead of having a best practice way to consolidate enhancements into a single useful library.

Has anyone else recognized this as a problem?  Is there an easy solution I am just missing?  

-Mike