[wp-trac] [WordPress Trac] #22896: Prevent plugins from overriding jQuery in the admin

WordPress Trac noreply at wordpress.org
Wed Jan 23 21:11:07 UTC 2013


#22896: Prevent plugins from overriding jQuery in the admin
------------------------------------+------------------
 Reporter:  nacin                   |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  3.6
Component:  External Libraries      |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+------------------

Comment (by auniquename):

 I am faced with a similar problem, only in reverse. When the core wp
 included jquery and jquery ui changes, the plugin I am working on will
 likely break. Yes, one should keep pace with wp revisions and maintain
 their plugin, but the work to support multiple wp and jquery versions in a
 plugin will quickly snowball and reduce the code to a horrific snafu. It
 would be nice to be able to produce software that will run unmaintained
 for at least a year or two. Quarterly updates and a bazillion version
 checks and conditionals seems silly to me.

 You see, I want to use jquery ui 1.10.0 in my plugin as it includes fixes
 that will make my life much easier. My development version of my plugin
 currently uses the wp bundled jquery and jquery ui as it is intended to be
 used, but makes performance and polish concessions to do so. Then when wp
 3.6, 3.7, 3.8 ... come out with new bundled js libs, it is going to be a
 nightmare to maintain. I am sure I am not the only one in this dilemma,
 though perhaps few think it through as thoroughly as I...

 Basically, my plugin makes heavy use of jquery ui dialogs and fully scoped
 css jquery ui themes. I am thinking of compatibility and isolation from
 the start. However, using fully scoped jquery ui themes results in issues
 that the jquery ui team had not thought of until recently and have only
 begun to address in v1.10.0.

 So if I want to use jquery 1.9.0 and jqueryui 1.10.0 in my plugin I am
 going to have to bundle it and isolate it somehow. This would give me the
 performance, and functionality I desire but runs the risk of contaminating
 the wp core if not done properly.

 My plugin will produce considerably amounts of dynamically generated
 javascript. So far the only thing I can think of to achieve the desired
 result and have a plugin that works for more than a few months without
 constant maintenance, is to include my required js libs with my
 dynamically generated js functions all wrapped into a single anonymous js
 function generated on the fly in php.

 This is a two way street, and the current situation sucks for traffic
 going either way.

 Long story short, I think wp needs to seriously rethink how it implements
 bundled js libs. The whole *_enqueue_script concept may just have to go
 eventually. Leave it there for old plugin compatibility but deprecate it
 and finally remove it, then establish a standard for isolating js lib
 dependencies.

 If I am thinking seriously about this for my own plugin then I think that
 the core wp coding team should be having similar thoughts. Sure it is a
 lot of work and not ideal, and will result in large amounts of revisions
 throughout the product. But if I have to make such concessions for a
 stable plugin that does not disturb the wp core, then I think the core
 should be taking similar steps to protect itself.

 I'm still stewing this over in my head and have not yet decided on the
 proper solution. But for now wrapping it all with the required libs in one
 anonymous function is all I have.

 Another approach might be a rethought js lib loader, one that plugins and
 the core alike can use, but differing from the current one in that it
 would sandbox each and every lib registered with it. I hate the idea of
 using cdns for js libs, again for software stability and lifetime
 considerations. It makes no sense for a site or code to depend on others
 that may or may not be there in the future.

 Apologies for the long post, and it may not help much, but this is a
 complicated problem that needs a solution in order to produce stable
 software with a reasonable shelf-life. If I come up with a good solution I
 will surely let you know.

 Sorry... more... a little research on the older approaches:
 http://sourceforge.net/projects/jsloader/ (virtually ancient at this
 point)
 http://www.andresvidal.com/jsl (better but still does not solve the
 problem)
 http://code.google.com/p/javascript-loader/ (looking pretty weak, and
 stale...)
 https://github.com/getify/LABjs (oh I remember this guy! but look at the
 readme...)
 https://github.com/jrburke/requirejs http://requirejs.org/ (now we're
 getting somewhere...)

 What's this AMD pattern? A quick Bing ... (Google is evil now with a
 cloaked tracking redirect on all result links, anyway...) So what is "the
 AMD pattern"?
 http://unscriptable.com/code/Using-AMD-loaders/

 AMD = Asynchronous Module Definition Aha! Well what exactly is that? The
 previous link begins to explain...

 http://www.commonjs.org/specs/

 And lists these as choices:
 RequireJS http://requirejs.org/
 curl.js http://github.com/unscriptable/curl
 bdLoad http://bdframework.org/bdLoad
 JSLocalnet http://www.localnet.org.es/
 Yabble http://github.com/jbrantly/yabble
 PINF http://github.com/pinf/loader-js

 And interestingly:
 cssx http://github.com/unscriptable/cssx
 XStyle http://github.com/kriszyp/xstyle

 define() huh? Hmmm...

 http://unscriptable.com/2011/09/30/amd-versus-cjs-whats-the-best-format/
 https://github.com/amdjs/amdjs-api/wiki

 I think I'm going to take a good look at RequireJS. I don't think it will
 solve this problem, but might get me closer to a solution. I suspect the
 answer may be to create an AMD fork of jquery and jquery ui, or better yet
 just get the jquery people to adopt it.

 The answer is out there and it is up to people like us to push for the
 solution. (sorry for all the link spam and long rambling post, but I'm
 just getting back into web development and writing things out brainstorm
 style helps me sort it all out..)

 Bottom line, in my opinion there needs to be major changes to both wp and
 jquery to solve this problem in the long term, but I'll see what kind of
 band-aids I can come up with in the meantime

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22896#comment:29>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list