Calling all developers! Registering javascripts... lets reuse the ones already there

Can we get a “best practice” recommendation? How about a 1st Party Extension called jQuer-EE-CP whose sole purpose is to load jQuery in the Control Panel, and developers should check for its presence if they want to use jQuery? I could have written 3 more useful addons in the time it’s taking to figure out this script issue!

For 1.x we’re happy to yield to what you all want to use. I don’t think it would help or hinder matters for us to slug an add-on up on the site that did this check for you - users would still need to know about and install it.

And for 2.0, well, jQuery’s going to be on every CP page anyway.

Thanks, Derek - 2.0 will be wonderful in its jQueryness, I’m sure.

Thing is, I know we have to first wait for (at least) 1.6.5 to be released before 2.0, so there’s plenty of time to be concerned with how we’re going to handle things right now (even after 2.0 comes out there will be plenty of 1.x installs out there). For me, it’s getting very common to load numerous extensions on every build that make use of jQuery.

I know nGenWorks wrote an extension solely to load jQuery in the CP header (CP jQuery). Not sure how viable that is as a solution for this problem. Maybe that’s a good start towards a Certified way to add jQuery to the CP.

I envision it working somewhat like Leevi’s LG Addon Updater. There is a hook in the jQuery extension, and we can add a method and put a function in our extensions that looks for the presence of the jQuery extension. In much the same way I am now making my extensions “compatible with LG Addon Updater”, I would make them “jQuery CP aware”. If LG Addon Updater isn’t installed, there’s no harm. Maybe there could be a fallback way to call jQuery (same way we’re doing it now) if the jQuery extension/hook isn’t found or utilized.

Sure, developers will need to know it’s there to use it, but when everyone chimes in on a thread saying that so-and-so developer’s extension doesn’t play nice with everyone else’s, then so-and-so developer might look at updating their work.

I don’t disagree, Ryan, I just don’t think that having a first party solution as an add-on will do much to alleviate that issue, and jQuery will not be included with any release of 1.x. There’s another approach to this for developers, as well. As juicy as jQuery is, is it absolutely necessary for your extension/module’s back end? There have been a number of add-ons floated past the dev team that utilize jQuery, seemingly for the sake of using jQuery.

You know, I might use nGenWorks jQuery Extension as a base and try some experiments based on my thoughts about Leevi’s Addon Updater.

Many of these extensions utilize JavaScript - and I’m sure a number of them could be re-written without relying on a library, but I’m not going there with some of these - particularly MD Markitup.

Well, you’re extension relies on a third party js editor that’s itself requires jQuery, there’s a difference between that and something that uses jQuery so that the Corner plugin can be used to round some containers, or to make a basic AJAX call.

OK, this is what I’ve done, and it seems to be working OK.

I downloaded nGenWork’s CP jQuery Extension. (I made a few tweaks, which I’ll get to). I install that. I looked in the Extensions table and it goes in there with a priority of 1, which I think is fine…it’s loaded way early in the process, before all the other extensions.

I can confirm that MD Markitup, LG Live Look, and LG Data Matrix (all of which call jQuery) do not call jQuery at all when CP jQuery is installed (which is exactly what we want) - meaning jQuery is only loaded once, and really early on in the process of showing the control panel. The three extensions in question all use code that looks similar to this:

if(empty($SESS->cache['scripts']['jquery']['1.2.6']) === TRUE)
{
  $js .= "\n< script type='text/javascript' src='{$this->settings['jquery_path']}'>< /script >";
  $SESS->cache['scripts']['jquery']['1.2.6'] = TRUE;
}

So, I just added that to the CP jQuery Extension. I set the extension to load jQuery 1.2.6, added the $SESS global to the “add_js” function, and changed this:

if ($s['load_jquery']) {
  $replace .= '< script type="text/javascript" src="' . $s['jquery_src'] . '">< /script>';
}

to this:

if ($s['load_jquery']) {
  $replace .= '< script type="text/javascript" src="' . $s['jquery_src'] . '">< /script>';
  $SESS->cache['scripts']['jquery']['1.2.6'] = TRUE;
}

I also made some other modifications to CP jQuery that aren’t related to this issue.

Anyway, installing this extension with that tweak seems to fix some conflicts because it loads so early and sets that $SESS variable. Will it work in all cases? No. But for the majority of Leevi’s extensions as well as a few of my own (as well as any other that wraps their jQuery script with that check), it seems like it will do the trick.

Thoughts, suggestions, or improvements are more than welcome.

In the interest of being thorough, here is a JavaScript solution (untested) that might be of some use from Karl Swedberg:

(function() { 
    if (typeof jQuery == 'undefined') { 
      var scripts = ['jquery.js', 'myCustomScript.js']; 
      var head = document.getElementsByTagName('head')[0]; 
      for (var i=0; i < scripts.length; i++) { 
        var newScript = document.createElement('script'); 
        newScript.setAttribute('src',scripts[i]); 
        head.appendChild(newScript); 
      } 
    } else { 
      $.getScript('myCustomScript.js', function(){ 
       //optional stuff to do after getScript; 
      });     
    } 
  })();

Glad the extension is helping. We thought it made sense to load as an extension since so many modules and other extensions make use of javascript.

if ($s['load_jquery']) {
  $replace .= '< script type="text/javascript" src="' . $s['jquery_src'] . '">< /script>';
  $SESS->cache['scripts']['jquery']['1.2.6'] = TRUE;
}

That’s perfect and exactly what I would have done. nGens jQuery extension is a great idea and something that made perfect sense. I would like to see Ellislab run with the idea for version 1.6.5 with nGens blessing and create a first party extension that is bundled with the install, although not necessarily activated.

It might take some time but I’d be happy to rewrite all my extensions to work with it.

I think it could be taken one step further and include jQuery UI (broken down into core modules) so they could be included on a per need basis.

Sorry for the late reply… I wasn’t getting emails :(

We would definitely support that being included. I think it would help out a lot of developers as we can see from this thread 😊

This thread has become a great discussion and I think we’re getting close to something usable for the 1.x branch that will help eliminate conflicts.

Correct me if I’m wrong, but I wouldn’t think we’d have to rewrite our extensions to use this extension - other than making sure to wrap your jQuery (and possibly UI) script tags(s) with the check for the $SESS variable so they don’t get output in the case jQuery was already loaded. I’ll continue to include a setting in my extensions for jQuery that will be output in the case I don’t have CP jQuery installed (which will be rare once we get it where it needs to be - the first two Extensions I’ll be installing will be LG Addon Updater and CP jQuery).

Anyway, however we can most quickly agree on how this extension should be structured is good with me. To recap, I’m using it now with these small changes:

Set my settings to the Google AJAX APIs:

$settings['jquery_src'] = 'http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js';
$settings['jquery_ui_src'] = 'http://ajax.googleapis.com/ajax/libs/jqueryui/1.5.2/jquery-ui.min.js';

Changed it so that instead of adding the script to the beginning of the head, it is added to the end (I’m under the impression that JS should be further down on the page - I always have it as close to the closing head tag as possible). Besides, the priority on this extension is ‘1’, so it will still show above every other block of script used by other extensions (which are typically priority 10 or 11):

$find = '</head>';
$replace = '';

if ($s['load_jquery']) {
  if(empty($SESS->cache['scripts']['jquery']['1.2.6']) === TRUE)
    {
      $replace .= '<scr1pt type="text/javascript" src="'.$s['jquery_src'].'"></scr1pt>';
      $SESS->cache['scripts']['jquery']['1.2.6'] = TRUE;
  }
}

if ($s['load_jquery_ui']) {
 if(empty($SESS->cache['scripts']['jquery']['ui']['core']['1.5.2']) === TRUE)
 {
  $replace .= '<scr1pt type="text/javascript" src="'.$s['jquery_ui_src'] . '"></scr1pt>';
  $SESS->cache['scripts']['jquery']['ui']['core']['1.5.2'] = TRUE;
 }
}

$html = str_replace($find, $replace."\n".$find, $html);

return $html;

I imagine those inputs/settings need to be cleaned and/or checked to be really secure, and make this more of a “certified-level” extension. I’m also not clear on whether there needs to be a version check, or whether we can just get by checking for the script without it.

Okay I had a look at the CPjQuery extension, and I think it’s not a bad idea. There are some things I’d change about it before considering inclusion in the application, but I’ll take those to Travis privately to see if he’s interested in accommodating those changes, failing that, I don’t see a good reason not to include a first party extension in the download for 1.6.5 by default.

Wow, that’s really good news. Travis - get on any changes ASAP! I’m extremely interested in a solid Derek-Jones-changes-incorporated 3rd-party version for use until 1.6.5.

Yay for Derek, Travis and everyone else in this thread!

The only real problem I see is still around version numbers, but maybe we can ignore those for now if EE includes the required jquery libraries.

@Ryan,

jQuery 1.6 UI is out with a bunch of bug fixes so you may want to consider using that.