[wp-hackers] Facebook API and WordPress Plugin Development - Insight / Best Practice
mike at newclarity.net
Thu Nov 15 04:32:00 UTC 2012
On Nov 14, 2012, at 10:42 PM, John Blackbourn <johnbillion+wp at gmail.com> wrote:
> On 15 November 2012 01:19, Mike Schinkel <mike at newclarity.net> wrote:
>> 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.
> Surely all this can be avoided by simply using namespaces in PHP. If I
> bundle API X in my plugin and namespace it, then another plugin can
> include the same or a different version of API X and there will be no
I don't see how PHP namespaces address the problem I posed. What am I missing?
Here's how I see it. If I'm using a published and tested version of Mark Jaquith's transient library in my plugin and you are use a later published and tested version of Mark Jaquith's transient library. Both of those version are still going to have used the same namespace:
So if we both want to use a non-forked version of the library that Mark published we still have the same problem, right?
Also, PHP namespaces require PHP 5.3 and since WordPress supports 5.2.4 using namespaces it is not even an option to solve the problem of using shared libraries in a WordPress plugin or theme.
Finally, what I proposed is two functions probably less than 40 lines of code each. Is that really so much to avoid if using it would potentially solve a real problem?
More information about the wp-hackers