[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