theme and plugin authors were warned early on about this change
Thread Starter
Deni
(@dennis_f)
Thanks for your reply!
Many jQuery plugins have nothing related with WordPress – people just would need some time to make their plugins compatible with the new jQuery 1.7
In my case, even as I am aware of this change, I am with tied hands until the developers of the plugin release an update and I am sure there will be lots of other plugin/theme developers with this problem.
jQuery 1.7 has been released just a few days ago and many people wouldn’t have the time to release updates that quickly.
+1 here, it takes at least a month for most plugins (providing high level support) to be updated and compatible with 1.7. Some of our custom code is also broken and we had to spend several days clarifying issues even though we’ve been testing for a while.
It’s possible, but I doubt you’ll see a reversion.
Instead, it might be a good idea to petition for a longer-than-usual Release Candidate cycle, to allow time for Plugin developers to deal with incompatibility issues.
Also, it might be a good idea to list any known incompatibilities with third-party scripts (i.e. NOT WordPress Plugins, but rather things like the Nivo Slider script, that would be out of the control of WordPress Plugin developers).
@chip, lots of themes are affected too. For instance, the jQuery UI scripts are in a new directory and renamed as well which makes all the themes using widgets, tabs and core of jQuery not supported by default until author revision.
Mario,
I didn’t intend to exclude Themes. 🙂
Unless I’m missing something, though, since WordPress 3.3 includes ALL jQuery UI Plugins rather than merely the Plugins used by WordPress core, enqueueing jQuery UI Plugins should be considerably easier for Themes now, right?
That is: since all Plugins are core-bundled, the enqueue call should only need to reference the core-registered jQuery UI Plugin script name, rather than the full filepath. Themes no longer have to bundle/register jQuery UI Plugins that were formerly not included in core.
@chip,
Browsing on both my notebooks comparing the 3.2.1 and the 3.3b3 jquery and UI folders what I see is the following:
1) the jquery.ui.* scripts are moved to the /ui folder and renamed respectively
2) 14 jquery.effects files are added to the /ui folder missing in the 3.2.1 release
So my question is – why didn’t core developers let ui.* stuff as it has been before and created an effects folder for the new scripts?
I just don’t see anything so useful here except for the awesome compatibility issue that is going to be out there in few days/weeks 🙂
1) the jquery.ui.* scripts are moved to the /ui folder and renamed respectively
2) 14 jquery.effects files are added to the /ui folder missing in the 3.2.1 release
So my question is – why didn’t core developers let ui.* stuff as it has been before and created an effects folder for the new scripts?
I might be a bit slow today 🙂 but I’m still not understanding the problem.
If a Theme or Plugin needs to enqueue a jQuery UI Plugin, and that Plugin is registered by core – no matter where the Plugin lives in the file structure – the Theme/Plugin simply calls:
wp_enqueue_script( 'jquery-ui-{pluginname}' );
What am I missing?
I’ve seen themes workaround’ing the standard enqueue_* functions for performance (page speed/yslow) to combine scripts loading in one file (when several CSS or JS files are included). This doesn’t work with the @import Css statement for synchronous reasons as well so I can recall some examples creating or using a parser outputting one file when 10+ scripts are passed as input.
I know this is not the standard behavior, but in case of some large plugins or themes work this way, this means that the impact at the end is serious.
Personally I don’t know of a core way in WordPress do design a combiner for CSS or JS files based on the wp_enqueue functions. Could the lack of my experience too?
Edit: probably using the ob_ buffers when calling enqueues but this should be attach at the appropriate place…
I’ve seen themes workaround’ing the standard enqueue_* functions for performance (page speed/yslow) to combine scripts loading in one file (when several CSS or JS files are included).
Themes that are doing this are _doing_it_wrong(). For one, core-bundled scripts should not be circumvented. For another, WordPress already concatenates enqueued scripts, IIRC.
Never seen a tutorial/post on concatenation/streaming of many css/js resources in WP. It doesn’t mean that themes don’t do it too (have seen many tutorials on combiners though).
Thread Starter
Deni
(@dennis_f)
I did a quick research about the Nivo slider problem with jQuery 1.7 (they haven’t released a new update yet), and it turns out that the problem is related with a bug in jQuery 1.7:
http://bugs.jquery.com/ticket/10669
(as I understand it will be fixed in the next jQuery 1.7.1)
I still think that it is too early to include that new version of jQuery just a few days after its release, having that the library itself has some bugs that will affect lots of other jQuery plugins.
We’re on jQuery 1.7.1 now – http://core.trac.wordpress.org/ticket/19326
Is this good to go now, or do we still have issues?
Thread Starter
Deni
(@dennis_f)
@ipstenu
For me everything is working fine now – the Nivo slider works well now – it is great that this jQuery 1.7 issue won’t be included in the next WordPress 🙂
Thank you all guys for all the work you do to make WordPress such a great software and for caring about users’ experience on the forum here!
(Sorry for now writing about this earlier – I was very busy the last few days)
No worries, dennis_f! And I shall flag this resolved!
Just cleaning as much up a I can before RC1 hits!
