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

Mike Schinkel mike at newclarity.net
Thu Nov 15 01:19:51 UTC 2012

On Nov 14, 2012, at 7:13 PM, Otto <otto at ottodestruct.com> wrote:
> On Wed, Nov 14, 2012 at 5:22 PM, Mike Schinkel <mike at newclarity.net> wrote:
>> Has anyone else recognized this as a problem?  Is there an easy solution I am just missing?
> No, there is no easy solution. Nor do I think the problem is a
> universally soluable one...

I agree that there is no panacea and that there will always be further edge cases no matter what we solve.  But I also think we can improve the 20% of use-cases that happen 80% of the time.

> The way I tend to solve it is to avoid using libraries at all,
> whenever possible. 

That approach results is very little ability for people outside of core to collaborate on improved APIs. It keeps 3rd party APIs from getting good enough and widely used enough to be considered for use in core (plugins are viable for end-user functionality, not for APIs.)  

Our current state of affairs is we are metaphorically all speaking different languages while we stare at the Tower of Babel instead of working to build it taller. :(

> Again, I don't think the problem is capable of solution. 

I think this can easily be addressed for the 20% use-case, and here is how:

Add a "register_library()" function to WordPress that accepts the following parameters, to be called by a plugin or theme within an 'init' hook:

	Library Name
	Version of this library
	Filepath of the file to require()
	Rules: Load Latest or Load this Version.

Then call a 'load_libraries()' function after the 'after_setup_theme' hook to load the latest version of each library. If there is a conflict don't load the library and display an error message inside the admin for the administrator to see and take appropriate action about while plugins are in conflict.

Easy peasy.

With the exception of the load latest vs. load current version we've already implemented something like this (although in hindsight I would do it a bit differently.)  Problem is this functionality really needs to be in core because it's like the Highlander; there can be only one because if is it ever updated then we have the same problem all over again.


Will this solve all versioning problems?  No, but it will enable code to be most safely shared than we have today.  

Having this would really help spur collaboration and innovation in the API space for WordPress.  I'm hoping others see the value of and the need for this too.


More information about the wp-hackers mailing list