Multiple versions of jQuery - getting beyond a joke.

[Geraint Edwards]

I loaded a typical Joomla webpage today and discovered that it was
loading 4 DIFFERENT versions of jQuery - these were thankfully
compressed by mod_deflate but it still added up to 280KB (uncompressed >
800KB of javascript for ONE PAGE)!!

The culprits were K2, JomSocial, Virtuemart2 and an Atristeer template.
I could easily envisage adding a couple of fancy modules that also load
their own versions. I wonder what the record is? I'm sure its >1GB of
jQuery scripts on one webpage.

THIS IS GETTING BEYOND A JOKE.

From what I can see the obvious solution is for 3rd party developers
who insist on using jQuery to use a common version loaded by a system
plugin or installable library. Developing such a plugin is not the
responsibility of the core Joomla developers - in fact there appear to
be several candidates already available
http://extensions.joomla.org/extensions/core-enhancements/scripts

This sort of abuse of bandwidth (and hence ultimately the environment)
is not appropriate and should some to an end.

So please, developers who use jQuery, get your act together and agree a
common approach to solving this ridiculous state of affairs.

Geraint

[Hannes Papenberg]

Since Joomla now no longer enforces mootools in the frontend, too, and
since I just had to create a project using jquery, let me introduce this
too:
<BIG_RANT_AGAINST_JQUERY />

Lets please get people back to using a sane JS framework. kthxbye

Hannes

[Matt Thomas]

Geraint,

Isn't there some sort of programmatic way to check to see if jQuery is already loaded, and if it isn't load it? If that is the case, I think that technique needs to be publicized among developers to help the situation. Maybe we need a core plugin to do that?

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

Geraint

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Geraint Edwards]

A core/system plugin that loads jQuery as a behaviour (so that its only loaded once) is the best solution in my mind.��

Javascript can check if jQuery is already loaded but that test is too late since you've probably reloaded it already.� I don't think there is a php/Joomla mechanism you can use to check if its already loaded.

Geraint

p.s. Hannes, I agree entirely about Mootools being perfectly adequate but feel that another mootools vs jquery arguement is a distraction from the immediate issue.� Loading 1GB of jQuery scripts is going to make Joomla a laughing stock (or worse) to many people so something needs to be done sooner rather than later about this.

On 05/01/2012 14:39, Matt Thomas wrote:

Geraint,

Isn't there some sort of�programmatic�way to check to see if jQuery is already loaded, and if it isn't load it? If that is the case, I think that technique needs to be publicized among developers to help the�situation.�Maybe we need a core plugin to do that?

Best,

Matt Thomas

Founder�betweenbrain�

Lead Developer�Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github:�https://github.com/betweenbrain

On Thu, Jan 5, 2012 at 8:52 AM, Geraint Edwards <joomla_...@copyn.plus.com> wrote:

I loaded a typical Joomla webpage today and discovered that it was loading 4 DIFFERENT versions of jQuery - these were thankfully compressed by mod_deflate but it still added up to 280KB (uncompressed > 800KB of javascript for ONE PAGE)!!

The culprits were K2, JomSocial, Virtuemart2 and an Atristeer template. �I could easily envisage adding a couple of fancy modules that also load their own versions. �I wonder what the record is? I'm sure its >1GB of jQuery scripts on one webpage.

THIS IS GETTING BEYOND A JOKE.

>From what I can see the obvious solution is for 3rd party developers who insist on using jQuery to use a common version loaded by a system plugin or installable library. �Developing such a plugin is not the responsibility of the core Joomla developers - in fact there appear to be several candidates already available http://extensions.joomla.org/extensions/core-enhancements/scripts

This sort of abuse of bandwidth (and hence ultimately the environment) is not appropriate and should some to an end.

So please, developers who use jQuery, get your act together and agree a common approach to solving this ridiculous state of affairs.

Geraint

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Thomas Kahl]

> A core/system plugin that loads jQuery as a behaviour (so that its only
> loaded once) is the best solution in my mind.

I also think so...

A more simple approach would be a standard set of defines that could
be used for several thing to check.

Until then, it should be good practice for extension developers to add
a configuration setting if jQuery should be loaded by the extension

Thomas

On 5 Jan., 09:55, Geraint Edwards <joomla_take...@copyn.plus.com>
wrote:

> A core/system plugin that loads jQuery as a behaviour (so that its only
> loaded once) is the best solution in my mind.
>

> Javascript can check if jQuery is already loaded but that test is too

> late since you've probably reloaded it already.  I don't think there is

> a php/Joomla mechanism you can use to check if its already loaded.
>
> Geraint
>
> p.s. Hannes, I agree entirely about Mootools being perfectly adequate
> but feel that another mootools vs jquery arguement is a distraction from

> the immediate issue.  Loading 1GB of jQuery scripts is going to make

> Joomla a laughing stock (or worse) to many people so something needs to
> be done sooner rather than later about this.
>
> On 05/01/2012 14:39, Matt Thomas wrote:
>
>
>
>
>
>
>
> > Geraint,
>

> > Isn't there some sort of programmatic way to check to see if jQuery is

> > already loaded, and if it isn't load it? If that is the case, I think
> > that technique needs to be publicized among developers to help

> > the situation. Maybe we need a core plugin to do that?
>
> > Best,
>
> > Matt Thomas
> > Founder betweenbrain <http://betweenbrain.com/>�

> > Lead Developer Construct Template Development Framework

> > <http://construct-framework.com/>
> > Phone: 203.632.9322
> > Twitter: @betweenbrain
> > Github:https://github.com/betweenbrain

>
> > On Thu, Jan 5, 2012 at 8:52 AM, Geraint Edwards

> > <joomla_take...@copyn.plus.com <mailto:joomla_take...@copyn.plus.com>>

> > wrote:
>
> >     I loaded a typical Joomla webpage today and discovered that it was
> >     loading 4 DIFFERENT versions of jQuery - these were thankfully
> >     compressed by mod_deflate but it still added up to 280KB
> >     (uncompressed > 800KB of javascript for ONE PAGE)!!
>
> >     The culprits were K2, JomSocial, Virtuemart2 and an Atristeer

> >     template.  I could easily envisage adding a couple of fancy
> >     modules that also load their own versions.  I wonder what the

> >     record is? I'm sure its >1GB of jQuery scripts on one webpage.
>
> >     THIS IS GETTING BEYOND A JOKE.
>
> >     >From what I can see the obvious solution is for 3rd party
> >     developers who insist on using jQuery to use a common version

> >     loaded by a system plugin or installable library.  Developing such

> >     a plugin is not the responsibility of the core Joomla developers -
> >     in fact there appear to be several candidates already available
> >    http://extensions.joomla.org/extensions/core-enhancements/scripts
>
> >     This sort of abuse of bandwidth (and hence ultimately the
> >     environment) is not appropriate and should some to an end.
>
> >     So please, developers who use jQuery, get your act together and
> >     agree a common approach to solving this ridiculous state of affairs.
>
> >     Geraint
>
> >     --
> >     You received this message because you are subscribed to the Google
> >     Groups "Joomla! CMS Development" group.
> >     To post to this group, send an email to
> >     joomla-...@googlegroups.com

> >     <mailto:joomla-...@googlegroups.com>.

> >     To unsubscribe from this group, send email to
> >     joomla-dev-cm...@googlegroups.com

> >     <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

[Geraint Edwards]

On 05/01/2012 20:25, Thomas Kahl wrote:
>> A core/system plugin that loads jQuery as a behaviour (so that its only
>> loaded once) is the best solution in my mind.

> I also think so...
>
> A more simple approach would be a standard set of defines that could
> be used for several thing to check.
>
> Until then, it should be good practice for extension developers to add
> a configuration setting if jQuery should be loaded by the extension
>

In essence adding a 'registry' entry to say 'jQuery' has been loaded.

I guess one problem to address would be that an old system plugin may
load jQuery 1.5 when another needs jQuery 1.7.

What I'm not sure about is how to get the developers that are causing
this problem to start talking to each other about the best solution.
There was a discussion over 1 year ago at
joomla-de...@googlegroups.com started by Joe leBlanc (he refers to
a closed discussion group here
http://people.joomla.org/groups/viewdiscussion/783-Best+practices+for+extension+developers+using+jQuery.html?groupid=445
- I can't access it so no idea what was discussed).

Geraint

[Andrew Eddie]

For what it's worth, we'd entertain putting jquery into the platform providing someone does all the work of wiring it up (not impossible, but not a trivial task). jQuery is not a JavaScript framework but it's got the market share and it's just not worth fighting that anymore. My suggestion is that some people get their heads together and devise a strategy for supporting js with mootools, jquery and/or other major players.

Regards
Andrew Eddie

[James Durrant]

Optional use of a Content Delivery Network (CDN) should also be considered.  

These examples are from the HTML5 boilerplate. They include a fallback for offline development.

https://github.com/h5bp/html5-boilerplate/blob/master/index.html (lines 48 and 49).

JQuery

    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>    

    <script>window.jQuery || document.write('<script src="/media/system/js/jquery-1.5.1.min.js">\x3C/script>')</script>    

MooTools

    <script src=" //ajax.googleapis.com/ajax/libs/mootools/1.4.1/mootools-yui-compressed.js"></script>    

    <script>window.MooTools || document.write('<script src="/media/system/js/jquery-1.4.1.min.js">\x3C/script>')</script>    

[Hannes Papenberg]

I would vote against a jquery specific solution in favour of a system that takes a name, a version and a path and at rendering time only provides the path for <name> with the highest version number. That would mean that you could use it for jquery, mootools, dojo and also for plugins for those frameworks. Intuitively I would make it a method of JDocumentHTML.

Hannes

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/LYIjmi_T_8kJ.

[Sam Moffatt]

If the core were to distribute jQuery, it should be a singular version
just as MooTools has been for the most part a singular version.
Otherwise we end up in a potential battle where people potentially run
into backwards compatibility issues. Doing JavaScript dependency
management is something that is non-trivial and would potentially lead
to conflicts due to something asking for a version and not getting it
at which point we've gone no where.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Hannes Papenberg]

I'm not saying to ship/provide jquery or whatever with the core with this feature, but to simply use it for injecting the include in the head and to prevent more than one jquery to be included. That would potentially reduce the code necessary in the behavior jhtml classes...

The extensions would still provide their own jquery, but Joomla would prevent them from being loaded except for the latest version provided by the extensions.

Hannes

[Jennifer Marriott]

How would that stop multiple versions Hannes?  Maybe I am misunderstanding?

[Hannes Papenberg]

Every extension that needs jquery provides its version and registers it with JDocumentHTML::addJSClass(). If then more than one extension registers a framework/class/plugin, Joomla compares the versions and only includes the latest version. So you register in your component or module and upon rendering the actual script tag in the head is generated.

[Robert Vining]

I would love to see a solution for this in 3.0

I've only been providing support for my commercial templates for 5 months now, but at least once a week I see multiple versions of jquery loaded by extensions that cause conflicts on the page and result in broken functionality.

I'm not experienced enough to code a solution like Hannes has mentioned, but I would do what I can to test anything anyone wants to work on to resolve this issue.

[Sam Moffatt]

What happens when a later version isn't compatible with an earlier
version? Or a later version? Case in point jQuery 1.6.0 broke
backwards compatibility with the .attr function (it was fixed with
1.6.1 mind you) and if you installed a new extension with 1.6.0, then
your site could be broken if you had older extension. At this point
we've really gone not that much more forwards: your site is still
vulnerable to being rendered dysfunctional by different versions used
by third party extensions. Except this time you're only loading one
version and it's breaking - so it breaks a little quicker.

To be honest I'm much more inclined to think providing a standard
JHTML::_('behaviour.jquery') is the best option and particular
versions are for a particular set of releases (e.g. one for 2.5, 3.0,
etc). Then at least you can check the version in Joomla! before you
load things and know that if you ask for jQuery you are assured of
getting a given version for a given release. Not too dissimilar to how
MooTools works.

Cheers,

Sam Moffatt
http://pasamio.id.au

On Fri, Jan 6, 2012 at 5:10 PM, Hannes Papenberg

[Geraint Edwards]

I also vote for

JHTML::_('behaviour.jquery')

since it provides developers with some certainty that the version they
anticipated will be the one they get. I have no idea if 6 monthly
updates would be enough, we really need the jQuery users to comment on
this and, I would argue, to step up to the plate to maintain a suitable
version.

Geraint

[Craig Phillips]

I think JHTML::_('behaviour.jquery') provides developers of 3P extensions the target they need but the updates should probably allow for bug fix updates to the the  jquery version as in the 1.6.0 => 1.6.1 example sighted.

So if 2.5 shipped with jQuery 1.7.1 then when 2.5.1 comes along it ships with the then current stable 1.7.x compatible version of jQuery.

Cheers

Craig

[Rouven Weßling]

To be honest I'd prefer not to include jQuery itself in the CMS. Besides being one more thing that will be hardly tested in between releases (since it isn't used in the CMS) I don't think we should encourage people too much to include both jQuery and MooTools.

It's relatively easy to write a system plug-in that it ether provides something like JHTML::_('jquery.framework') or - my personal preference - an override for JHtmlBehavior that not only provides jQuery but also overrides some of the other behaviors with jQuery code (keepalive and noframes should be relativly easy) to lessen the chance of people having to load both jQuery and MooTools.

Rouven

[Ofer Cohen]

+1 for JHTML::_('behaviour.jquery')
If someone require new (or downgrade) JQuery version, plugin can override this (same as we have with mootools).

Ofer Cohen

[Hannes Papenberg]

+1 for not including jQuery in the CMS. As I said earlier about jQuery
<INSERT RANT HERE>, which is why I don't really want to support it more
than necessary. (If you want, I can actually write my rant, but I'm not
sure its really helpfull right now for the discussion)

Yes, my proposal creates issues when newer versions of a JS library are
incompatible with older versions, but I see that as a problem of the
library, not from us. I'm actually wondering what is happening in case
you load two different versions of jQuery... Do they co-exist or does
one cancel out the other? Reading this it seems as if different versions
overwrite each other ... in a way:
http://forum.jquery.com/topic/multiple-versions-of-jquery-on-the-same-page
That would mean that a site that loads more than one jquery might as
well only load the latest and be done with it. The rest is just dead
weight that is not executed... (Have to admit, didn't test this...)

In any case, if this is true, the solution proposed by me would be
sufficient and would not require including another JS library (e.g.
jQuery) in our distribution.

Hannes

[Geraint Edwards]

Maintaining and testing jQuery should be the responsibility of those 3rd
party developers that want to use it.

We just need a volunteer :'( .

Given the high profile projects that now use jQuery (K2, JomSocial,
Virtuemart, Community Builder to name but a few) they should be able to
muster the resources to maintain and test this as either part of the
core or as a standalone plugin.

Geraint

[Brad Gies]

I'd put my vote on JHTML::_('behaviour.jquery') because it would be easy
to standardize a version. But, I wouldn't provide the framework and
instead loading a specific version (publicized of course) of jquery for
each version of Joomla and loading it from the Google Cloud.

It has the (HUGE) advantage that dev's would know the jquery version,
could download it easily, AND for users that browse more than one
Joomla! site, it would only have to be downloaded once.

For what it's worth... I think Mootools should be loaded the same way.
Has anyone given any thought to at least making this an option in the
admin panels? I haven't looked at it lately, but I have seen several
code samples for pulling Javascript from the cloud and falling back to
pulling it from your own site if the cloud is down for any reason
(unlikely, but possible).

It shouldn't be that tough to provide an option when setting up a site
to either rely totally on pulling the Javascript framework from the
cloud, or downloading the JS library installing it into the Joomla!
libraries, and then the site would try loading it from the cloud first
and fallback to the site, or just load the JS from the site every time.
Obviously, the default for the first version including this would be the
behaviour we have now (loading from the site), and we'd have to include
methods to be able to change your mind later, but it's all fairly doable
:).

Brad

[Hannes Papenberg]

I so absolutely don't want to make every Joomla installation pull its javascript from Google. If you do that, you might as well add a phone home feature that is enabled by default.

joomla-dev-cms@googlegroups.com.

To unsubscribe from this group, send email to

joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google
Groups
"Joomla! CMS Development" group.
To post to this group, send an email to

joomla-dev-cms@googlegroups.com.

To unsubscribe from this group, send email to

joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google
Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.

To unsubscribe from this group, send email to

joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups
"Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.

To unsubscribe from this group, send email to

joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups
"Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.

To unsubscribe from this group, send email to

joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups
"Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.

To unsubscribe from this group, send email to

joomla-dev-cms+unsubscribe@googlegroups.com.

For more options, visit this group at
http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Steven Sheeley]

Hannes,

   Can you help me understand why pulling the javascript libraries from the cloud, and transferring the bandwidth usage from your server to those servers, is the equivalent of "phoning home"?

Steven Sheeley Web Developer, Myndworx Asylum
steve....@gmail.com | www.myndworx.com | www.paranomicon.org

“

"The difference between school and life? In school, you're taught a lesson and then given a test. In life, you're given a test that teaches you a lesson." - Tom Bodett

”

  Get this email app!  

[Matt Thomas]

If anything, loading jQuery from Google should be configurable. In my opinion, it should default to a local copy as many times sites need to wait for it to load. I've also found it better for development purposes to load a local than from Google.

Just my 2 cents.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Mark Dexter]

My understanding is that we want Joomla sites to be self-sufficient by default and not dependent on external, third-party sites. One obvious application for this is an intranet, where the server might not even be connected to the web. There is absolutely no problem of course with site admins deciding otherwise for their specific situations. But out of the box we don't want to create dependencies for all Joomla users. Mark

[Ofer Cohen]

+1 for configurable when default is local.

Ofer Cohen

On 01/07/2012 08:21 PM, Matt Thomas wrote:

If anything, loading jQuery from Google should be configurable. In my opinion, it should default to a local copy as many times sites need to wait for it to load. I've also found it better for development purposes to load a local than from Google.

Just my 2 cents.

Best,

Matt Thomas

Founder�betweenbrain�

Lead Developer�Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github:�https://github.com/betweenbrain

<hack...@googlemail.com> �wrote:

Every extension that needs jquery provides its version and registers it with
JDocumentHTML::addJSClass(). If then more than one extension registers a
framework/class/plugin, Joomla compares the versions and only includes the
latest version. So you register in your component or module and upon
rendering the actual script tag in the head is generated.

Am 07.01.2012 01:30 schrieb "Jennifer Marriott"<marpomu...@gmail.com>:

How would that stop multiple versions Hannes? �Maybe I am

misunderstanding?

On Fri, Jan 6, 2012 at 6:28 PM, Hannes Papenberg

<hack...@googlemail.com> �wrote:

I'm not saying to ship/provide jquery or whatever with the core with this
feature, but to simply use it for injecting the include in the head and to
prevent more than one jquery to be included. That would potentially reduce
the code necessary in the behavior jhtml classes...

The extensions would still provide their own jquery, but Joomla would
prevent them from being loaded except for the latest version provided by the
extensions.

Hannes

Am 07.01.2012 01:18 schrieb "Sam Moffatt"<pas...@gmail.com>:

If the core were to distribute jQuery, it should be a singular version
just as MooTools has been for the most part a singular version.
Otherwise we end up in a potential battle where people potentially run
into backwards compatibility issues. Doing JavaScript dependency
management is something that is non-trivial and would potentially lead
to conflicts due to something asking for a version and not getting it
at which point we've gone no where.

Cheers,

Sam Moffatt
http://pasamio.id.au



On Fri, Jan 6, 2012 at 3:40 PM, Hannes Papenberg

<hack...@googlemail.com> �wrote:

I would vote against a jquery specific solution in favour of a system
that
takes a name, a version and a path and at rendering time only provides
the

path for<name> �with the highest version number. That would mean that

you
could use it for jquery, mootools, dojo and also for plugins for those
frameworks. Intuitively I would make it a method of JDocumentHTML.

Hannes

Am 06.01.2012 23:54 schrieb "James Durrant"<ja...@bigbang.ie>:

Optional use of a Content Delivery Network (CDN) should also be
considered.

These examples are from the HTML5 boilerplate. They include a
fallback for
offline development.

https://github.com/h5bp/html5-boilerplate/blob/master/index.html (lines 48
and 49).

JQuery

� � <script

src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
� � <script>window.jQuery || document.write('<script

src="/media/system/js/jquery-1.5.1.min.js">\x3C/script>')</script>

MooTools

� � <script src="

//ajax.googleapis.com/ajax/libs/mootools/1.4.1/mootools-yui-compressed.js"></script>

� � <script>window.MooTools || document.write('<script

src="/media/system/js/jquery-1.4.1.min.js">\x3C/script>')</script>

--
You received this message because you are subscribed to the Google
Groups
"Joomla! CMS Development" group.
To view this discussion on the web, visit
https://groups.google.com/d/msg/joomla-dev-cms/-/LYIjmi_T_8kJ.
To post to this group, send an email to

[Steven Sheeley]

I can understand the local requirements and am all for the configurability to allow the administrator to determine where he/she loads the files from, but I'm still confused as to what's "Phoning Home" if you're loading the library from the cloud.

Steven Sheeley Web Developer, Myndworx Asylum
steve....@gmail.com | www.myndworx.com | www.paranomicon.org

“

"Don't cry because it's over. Smile because it happened." - Dr. Seuss

”

  Get this email app!  

Want a signature like mine? CLICK HERE.  

On Sat, Jan 7, 2012 at 10:22 AM, Ofer Cohen <oc...@netvision.net.il> wrote:

+1 for configurable when default is local.

Ofer Cohen

On 01/07/2012 08:21 PM, Matt Thomas wrote:

If anything, loading jQuery from Google should be configurable. In my opinion, it should default to a local copy as many times sites need to wait for it to load. I've also found it better for development purposes to load a local than from Google.

Just my 2 cents.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

<hack...@googlemail.com>  wrote:

Every extension that needs jquery provides its version and registers it with
JDocumentHTML::addJSClass(). If then more than one extension registers a
framework/class/plugin, Joomla compares the versions and only includes the
latest version. So you register in your component or module and upon
rendering the actual script tag in the head is generated.

Am 07.01.2012 01:30 schrieb "Jennifer Marriott"<marpomu...@gmail.com>:

How would that stop multiple versions Hannes?  Maybe I am

misunderstanding?

On Fri, Jan 6, 2012 at 6:28 PM, Hannes Papenberg

<hack...@googlemail.com>  wrote:

I'm not saying to ship/provide jquery or whatever with the core with this
feature, but to simply use it for injecting the include in the head and to
prevent more than one jquery to be included. That would potentially reduce
the code necessary in the behavior jhtml classes...

The extensions would still provide their own jquery, but Joomla would
prevent them from being loaded except for the latest version provided by the
extensions.

Hannes

Am 07.01.2012 01:18 schrieb "Sam Moffatt"<pas...@gmail.com>:

If the core were to distribute jQuery, it should be a singular version
just as MooTools has been for the most part a singular version.
Otherwise we end up in a potential battle where people potentially run
into backwards compatibility issues. Doing JavaScript dependency
management is something that is non-trivial and would potentially lead
to conflicts due to something asking for a version and not getting it
at which point we've gone no where.

Cheers,

Sam Moffatt
http://pasamio.id.au



On Fri, Jan 6, 2012 at 3:40 PM, Hannes Papenberg

<hack...@googlemail.com>  wrote:

I would vote against a jquery specific solution in favour of a system
that
takes a name, a version and a path and at rendering time only provides
the

path for<name>  with the highest version number. That would mean that

you
could use it for jquery, mootools, dojo and also for plugins for those
frameworks. Intuitively I would make it a method of JDocumentHTML.

Hannes

Am 06.01.2012 23:54 schrieb "James Durrant"<ja...@bigbang.ie>:

Optional use of a Content Delivery Network (CDN) should also be
considered.

These examples are from the HTML5 boilerplate. They include a
fallback for
offline development.

https://github.com/h5bp/html5-boilerplate/blob/master/index.html (lines 48
and 49).

JQuery

    <script

src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>

    <script>window.jQuery || document.write('<script
src="/media/system/js/jquery-1.5.1.min.js">\x3C/script>')</script>

MooTools

    <script src="

//ajax.googleapis.com/ajax/libs/mootools/1.4.1/mootools-yui-compressed.js"></script>

[brian teeman]

The sample code posted earlier will always load local when the external is not available ie for an intranet or offline development

[Hannes Papenberg]

When you load your jquery for your site from Google, Google knows about every user that visits your site, about every installation of Joomla that you have and also which sites your users visited. This is close to the equivalent of putting everyone under 100% surveillance by Google. Yes, I use Google services, but I absolutely never ever trust them.

Simple example: you run a whistleblower website based on Joomla. The government goes to Google and forces them to hand over the logs who accessed the site and they can prosecute whistleblowers or even people just reading the site. And don't tell me that didn't/doesn't happen. Simply naming China, Iran or Burma should be enough.

The cloud is most likely the stupidest idea ever in terms of privacy.

[Matt Thomas]

Yes, and I've even used that code before. It's great.

However, I'd propose JHTML::_('behaviour.jquery') to be configurable in such a way that can load a local copy, or use the Google hosted one with an automatic fallback.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

[Beat]

6 quick feedbacks, as we use jQuery since years in CB without issues
thanks to non-conflicting coding:

1) NO to include from cloud: including Javascript from a third-party
site (specially google) is a *security issue*. Javascript has access
to your users' browser environment, and if breached can allow to do
many kind of attacks. E.g. it would not allow you to pass PCI-DSS as
your security audit can't encompass google ! . I have lately audited
several sensitive security-related sites, and that issue got
acknowledged as being a higher risk one.

2) jQuery is not only jQuery base library. There are many jQuery
plugins (with dependencies) and associated CSS files. Also jQuery code
outputed should always be in closures to avoid any conflicts. We have
designed a special framework for that in Community Builder, it's not
just a JHTML behavior.

3) document.write() is bad coding. It stops the browser execution and
triggers a redraw, slowing down page rendering.

4) just after including the jquery script you need to output
"jQuery.noConflict();" BEFORE loading anything using or defining "$",
e.g. mootools. Joomla's head document output doesn't allow that.

5) Since over 2 years, between teams cooperating with Community
Builder we have agreed to have a constant J_JQUERY_LOADED that CB and
other third party check to be not defined before loading and set to 1
after outputing the jquery base library include. Some developers check
for that, others don't. Not the most elegant solution, but easy enough
and works. It would be nice if there is no other mechanism agreed that
at least this constant be official

6) To support correctly jquery's needs (and other js libs's needs) in
joomla framework, it requires a small js loading framework that I'm
happy to write and contribute for Joomla 3.0 if you wish.

I feel it's a bit late for Joomla 2.5, but if there is interest and
help to incorporate and test it correctly, we can propose and
contribute our current jquery loading code to the framework.

Best Regards,
Beat
http://www.joomlapolis.com/

[Rouven Weßling]

Also a big no from me for loading Mootools or anything else from Google. Such a solution can be provided by a 3rd party plug-in. We really need to stop trying to cram everything into the core.

Rouven

[Matt Thomas]

I'm very much in favor of a slim core, but I think that this is one area where adding something can help solve a problem instead of just adding another feature the sake of the feature.

Best,

Matt Thomas

Founder betweenbrain™

Lead Developer Construct Template Development Framework

Phone: 203.632.9322
Twitter: @betweenbrain

Github: https://github.com/betweenbrain

On Sat, Jan 7, 2012 at 4:52 PM, Rouven Weßling <m...@rouvenwessling.de> wrote:

Also a big no from me for loading Mootools or anything else from Google. Such a solution can be provided by a 3rd party plug-in. We really need to stop trying to cram everything into the core.

Rouven

[James Durrant]

@rouven -  There's a difference between craming everything in the core and making the core extendible - I can't see how adding the ability to use your own source for a static asset would add more than 2 or 3 lines of code to the current platform or any variation of it; especially when there are so many other features that are heavier and less useful .

Static assets could be loaded from any CDN (cdn.mydomain.com) allowing parallel downloading. Personally I'd use Google (although I'll need to look further into @beats comments) because the library is likely pre-cached by the user's browser.

[Rouven Weßling]

On 08.01.2012, at 00:32, James Durrant wrote:

> @rouven - There's a difference between craming everything in the core and making the core extendible - I can't see how adding the ability to use your own source for a static asset would add more than 2 or 3 lines of code to the current platform or any variation of it; especially when there are so many other features that are heavier and less useful .

A general solution for CDN support is something different than allowing some files to be loaded from Google. Using the Google "CDN" only involves having a relatively simple plug-in which I'm sure is available somewhere already.

> Static assets could be loaded from any CDN (cdn.mydomain.com) allowing parallel downloading. Personally I'd use Google (although I'll need to look further into @beats comments) because the library is likely pre-cached by the user's browser.

I started writing some code that will eventually allow people to host the entire media folder on a different domain (for parallel loading and cookie benefits) or even a CDN. Unfortunately there's some disagreement over the API but maybe we'll get lucky for 3.0. ;)

Rouven

[James Durrant]

Great to know that you've looked into options on loading the media folder from an external source, but many optimised sites use more than one CDN . Giving an option to use a source that is most likely cached by the users browser will become more and more relevant as page speed becomes a dominating factor in cross search engine ranking . 3rd party plugins may have a harder task of modifying the static asset path depending the outcome of this discussion.

[Joe Palmer]

+1 for adding JHTML::_('behaviour.jquery') as a simple way for 3rd
parties to all use the same local instance of jQuery.

I did a talk on JavaScript frameworks at Joomla Day UK 2011 and came
to exactly this conclusion. Sides here if anyone is interested
(suggestions on last slide):

http://www.softforge.co.uk/resource-area/downloads/softforge/doc_download/13-javascript-frameworks

Beat, if you were to contribute this functionality for v3.0 I think it
would be a great service to Joomla and I would happily test it.

> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/joomla-dev-cms/-/UUjoW1Hkr00J.

[elin]

I just wanted to make a suggestion. We have a long jquery thread every few months. If a few major developers would just each  put up funding for 2 hours of developer time and have a two hour meeting to come to an agreement on how to solve in a common way most likely the whole issue would be solved and everyone else would just follow along. It just seems like a waste of time to rehash this over and over when these are businesses that pay developers and really, how hard is it to just sit down and write a plugin everyone agrees on?  And then do what Andrew says which is a more complicated thing but surely worth the money to your businesses to get done rather than spending your time on yet another workaround and/or another thread like this.

Elin

[Steven Pignataro]

We will fund and we will develop. How is next Friday sound for a meeting on this project?

Kindest regards,

--Steven Pignataro

[Peter van Westen]

Just to nit-pick.

It should be: JHTML::_('behavior.jquery') => US/code spelling

And not: JHTML::_('behaviour.jquery')  => Normal English spelling ;)

[Geraint Edwards]

On 07/01/2012 20:51, Beat wrote:
> 6) To support correctly jquery's needs (and other js libs's needs) in
> joomla framework, it requires a small js loading framework that I'm
> happy to write and contribute for Joomla 3.0 if you wish.
>
> I feel it's a bit late for Joomla 2.5, but if there is interest and
> help to incorporate and test it correctly, we can propose and
> contribute our current jquery loading code to the framework.
>

I don't think its completely too late for Joomla 2.5 since it can be
implemented as an installable system plugin for Joomla 2.5 prior to
Joomla 3.0.

As Elin says

"If a few major developers would just each put up funding for 2 hours
of developer time and have a two hour meeting to come to an agreement on
how to solve in a common way most likely the whole issue would be solved
and everyone else would just follow along."

What does it take to make this happen? It sounds as though CB is on
board with the concept :-) , now we just need the others ''major
developers' K2, Virtuemart, JomSocial etc. to get on board

Geraint

[Lobos]

This is correct - I took a vacation recently and did not have a connection so I was working completely on localhost (MAMP to be exact) and I can tell you now, Joomla is a bitch to work with without a connection - you just try and access the backend admin and see how long you need to wait for it to come up. Would be nice if there was a timeout (even 5 seconds) for the remote stuff it is loading...

[Localizador Imobiliário]

The core of Joomla should have an update alert to avoid this problem.
I checked the same situation and I noticed that there is no filter to update the extensions quickly.
If the core block of Joomla extensions with old parts, could be a way to force developers to upgrade the components, modules and plugins.
This already happens in other CMS.

2012/1/5 Geraint Edwards <joomla_...@copyn.plus.com>

I loaded a typical Joomla webpage today and discovered that it was loading 4 DIFFERENT versions of jQuery - these were thankfully compressed by mod_deflate but it still added up to 280KB (uncompressed > 800KB of javascript for ONE PAGE)!!

The culprits were K2, JomSocial, Virtuemart2 and an Atristeer template.  I could easily envisage adding a couple of fancy modules that also load their own versions.  I wonder what the record is? I'm sure its >1GB of jQuery scripts on one webpage.

THIS IS GETTING BEYOND A JOKE.

From what I can see the obvious solution is for 3rd party developers who insist on using jQuery to use a common version loaded by a system plugin or installable library.  Developing such a plugin is not the responsibility of the core Joomla developers - in fact there appear to be several candidates already available http://extensions.joomla.org/extensions/core-enhancements/scripts

This sort of abuse of bandwidth (and hence ultimately the environment) is not appropriate and should some to an end.

So please, developers who use jQuery, get your act together and agree a common approach to solving this ridiculous state of affairs.

Geraint

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-dev-cms@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.

[Rouven Weßling]

On 09.01.2012, at 18:38, Localizador Imobiliário wrote:

> The core of Joomla should have an update alert to avoid this problem.

Check out the beta for 2.5, update notifications have been added there. (Big thanks to Nic again here)

> I checked the same situation and I noticed that there is no filter to update the extensions quickly.
> If the core block of Joomla extensions with old parts, could be a way to force developers to upgrade the components, modules and plugins.
> This already happens in other CMS.
>

How are other CMSs forcing extension devs to update their extensions. Not sure I understand what you're saying.

Rouven

[Localizador Imobiliário]

There is a clear warning on the dashboard administrator stating the need for the update.
It is a way to force - warn about the update.
In all parts of the system - Drupal.

2012/1/9 Rouven Weßling <m...@rouvenwessling.de>

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.

To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.

[Rouven Weßling]

We'll have the same thing in Joomla 2.5!

Rouven

[Beat]

Okay, I took your proposal/challenge/task and invested last 2.5 days (not hours :-D) designing and implementing and testing a proposal for inclusion into Joomla 2.5.

The implementation comes from Community Builder's jQuery loader, but is a complete refactoring that goes a step further in the non-conflicting mode, allowing all extension developers to run the version of jQuery they need, concurrently without conflict, while sharing same major version of jquery and jQuery plugins.

Focus here is the admin user that installs extensions that have jQuery version dependancies, and needs them to run without conflict, and without loading multiple times same major version.

I started a new thread on the framework development list:

https://groups.google.com/group/joomla-dev-platform/browse_thread/thread/2d1916cd03c4303a?hl=en#

And made a pull request here to review the proposal:

https://github.com/joomla/joomla-platform/pull/736

I think it's easier to discuss on an existing design proposal and implementation, and I'm available to discuss this proposal on the new thread, including Thursday and Friday. ;)

Looking forward to your feedbacks. Try it, it's pretty staight-forward to use.

Let's see if this makes it into Joomla 2.5 (LTS) as we all hope to avoid another couple of years with jQuery conflicts... ;-)

[Dean Peterson]

Perhaps JavaScript libraries should be treated separately than the actual behavior scripts they support.

jDocument->registerScriptLibrary("jquery","/path/jquery.js","1.7.1");

Maybe all extensions should be "required" to register their scripts, listing their library dependencies:

jDocument->registerScript("myExt.js","myExt/Assets/myExt.js","jquery-1.6");

Also, what would it look like to move the script inserts from   <jdoc:include type="head" /> to  <jdoc:include type="scripts" />

I really would like to be able to load scripts into the bottom of my page rather than be forced to load at the top.  I know there are plugins that do that, but does everything have to be solved with a plugin?

For what it's worth.

Thanks

[Beat]

These are 2 different items imho.

1) where the javascript loading is done: I don't really care where it's loaded. I implemented it as "behavior.jquery" as that was looking like the consensus/directions in here.

2) template jdocs:

The compound   <jdoc:include type="head" /> should be kept for compatibility with existing templates, but could be composed of sub-variants that could be used instead of   <jdoc:include type="head" /> :

  <jdoc:include type="meta" />

  <jdoc:include type="styles" />

  <jdoc:include type="scripts-nondefered" />

  <jdoc:include type="scripts-defered" />

That way the template can be composed as wished depending on your website's needs. Keep in mind that a script in body triggers a draw and then a redraw at end. So typically putting the scripts at the end is ok, for those that do not change the page layout. Otherwise it will be looking jittery at rendering and less snappy.

That's why there is this async and defer attributes of HTML5, which are really the way to go instead of putting scripts at end, thus the second point will be less required with modern browsers.

It's pretty hard to tell in advance if scripts (and which ones) are needed before the rendering or not, specially general-purpose libraries as mootools and jquery, as it will depend on their particular use within extensions. Thus for general libraries it's only safe to load them not deferred.

[Alex Andreae]

I just read through all the code proposed, and have a few comments:
1) It's all very specific to jQuery, while still requiring the
developer to include their own library file. It seems like if the core
CMS isn't going to support a library officially, we shouldn't have all
the code in there to 'sort of support it'. I understand that's gotten
us to where we are, but it seems like the Mootools situation is much
better handled:
* Each Joomla release supports a specific version of Mootools. Even if
it's old and widely unused elsewhere, at least developers know what
version to target for Joomla x.y
* If we're going to support jQuery, I say we do it fully and include
the targetted release in the core. We then step through any bug-
release versions as necessary, but don't move to a new major version
until a new LTS. That matches our Mootools support, and doesn't make
the CMS's support for different JS libraries inconsistent.
* Alternatively, add the pre-script/post-script functions so
developers can basically work around jQuery conflicts on their own..
not have Joomla have extra weight for this specific library and case
which won't be used on all sites.

2) With specialized support for Javascript libraries, I can see this
getting out of hand. While we don't use jQuery, we use Facebook's
Javascript library for everything we do. The Facebook library can't be
included in the core (it's loaded from FB.com). However, Facebook has
3 different recommendations for how to load this one library.. and
they all can conflict depending on certain features that are required
and if it's loaded multiple times. There is a "best" way, but even it
should only be included on the page once.

The majority of our support requests revolve around conflicts in other
extensions re-loading (or incorrectly loading) the Facebook Javascript
library. Reading this thread makes me antsy to propose a JBehavior
call for loading the Facebook library in the most compatible way. I
think it would get tossed out immediately, but (arguably) Facebook is
used on as many Joomla sites as jQuery in one way or another.
Preventing those conflicts *would* be beneficial to the subset of
users that need it (similar to jQuery conflicts)

Really, I just wanted to call out that a half-implementation by the
CMS is going to lead to other problems of "Why isn't xxx supported",
and a similar discussion will be had. While the jQuery stuff is
annoying, I don't think it's a core thing to allow working around. It
seems to me that:
* Either include a standardized jQuery in the core, or
* Include the tools (pre-script/post-script) to make a plugin or
developer-agreed upon solution more feasible. This latter option also
benefits other developers using other conflicting libraries. Once we
fix the biggest conflicting extension, there will be another one
behind it.

Thanks,
Alex Andreae

[raramuridesign]

Hi All

Would it not make sense to encourage the following for the project & developers 

Joomla core

- allow the choice of which javascript to load, K2 does this in the backend, where you can select which library to load

- Even allow the option to load both mootools and jquery

- possible remote inclusion

- separate the jquery from backend and frontend

- make sure this sits outside of the head call

Developers

- if all developers allowed the option to either switch off / on the javascript library they are using

- if all developers made it clear in the component which javascript is being used, then users can make an educated choice in terms of which library to use which then helps choose modules and components.

The choice & discussion about which library to use will always be there.

Matthew

[Jeremy Wilken]

I also looked at the code, and it seems like we are specializing code rather than making it reusable in this approach. jQuery is popular, but the challenges of loading scripts automatically into the document head extend beyond jQuery. I agree with Alex here, there should be plugins or libraries for javascript libraries, and that is where we can consider placing the specific jQuery elements rather than inside the core. 

In Square One the concept of 'official extensions' is present. Currently they are the removed 60 extensions I've extracted from the current Joomal core, but the concept can be extended to include other extensions that have an elevated status. This makes it possible to have optional extensions, such as dependencies, made available in a semi-official format that is easy to include, but not by default. This is something Drupal does well, having one module to do a specific task, and letting other modules rope it in as a dependency rather than duplicating, and our plugin or library system could make this a reality. This means people would rely on the semi-official javascript library package, and develop accordingly. The jQuery package can even include the same functionality offered in this code by providing the ability to manage the plugins, multiple versions, etc.

Just like editors are a plugin type, I would much like to see a 'script' plugin group that would include MooTools, jQuery, and others. The simple answer is that you would just need to check a particular plugin is enabled, verses all of this library modification. On the other hand, we could generate a library for each script, and a generic parent class in the Platform that each library type can specialize.

Its really no different conceptually than the way that language packs work, there is an semi-official translation for each supported language thats registered with the project. One script library pack can be made for MooTools, jQuery, YUI, prototype, whatever. 

Thats my $.02, but I think it provides the power to the developers rather than making them rely on what is supported in the core.

[Duccio Gasparri]

+1 for the plugin solution. It's fast, easy, more customizable (as
plugins are customizable). And since jQuery IS one of the most popular
libraries around, 1+ also for distributing it with the standard joomla
installation

However, I had to put into my template the following code to avoid the
4+ loadings of jQuery. It would be nice if it would be done
authomatically, to prevent badly written extensions from loading their
jQuery



//Could be defined in the admin interface, with option for version or
CDN
$jQueryUrl = $this->baseurl.'/templates/XXXX/javascript/
jquery-1.7.1.min.js';

// Code inside the template, $this referring to the template caller
class
$this->addScript($jQueryUrl, 'text/javascript', false);

$headData = $this->getHeadData();
//$headData = array('scripts'=>$headData['scripts']); //Erases the
other entries

foreach($headData['scripts'] as $path => $values)
{
if($path == $jQueryUrl)
continue; //Saves our default installation of jQuery

if(false!== strcasepos($path, 'jquery')) {
// it was enough for me, but this also cancel jquery.ui and other
jquery-based sublibraries
//so it should be better specified
unset($headData['scripts'][$path]);
// Log Warning?
continue;
}
if(false!== strcasepos($path, 'otherJsLibrary(Ex. Prototype) if
necessary')) {
unset($headData['scripts'][$path]);
continue;
}

}


//This moves jQuery to the first place, and cleans the array from the
other values
$jQueryValues = $headData['scripts'][$jQueryUrl];
unset($headData['scripts'][$jQueryUrl]);
$headData['scripts'] = array($jQueryUrl => $jQueryValues) +
$headData['scripts'];

$this->setHeadData($headData);

unset($headData, $jQueryUrl, $jQueryValues);

[Rafael Corral]

I have implemented a different solution to the problem.
I added a place where javascript libraries can be registered and can be loaded, this way all 3rd party extensions can use these calls avoid the loading of multiple jquery libraries as there is no way to accurately tell if the library has been loaded or not.

I also added the jquery library as a Joomla plugin, this will avoid the core team having to support another javascript library.

Here is the pull request for the implementation:
https://github.com/joomla/joomla-cms/pull/116

Cheers,
Rafael