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

[CloudPress Hosting]

That I think the only was is up tot he class author to guard against by
using a distinct class name in each version he releases. Problem is you
can't always count on class authors to do that. But that issue I think
falls outside the scope of WordPress.


On Wed, Nov 14, 2012 at 3:22 PM, Mike Schinkel <mike at newclarity.net> wrote:

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