6 min read

The first thing that you should always do before making any changes is take a backup of your site. You can do this manually or by using an extension like Akeeba backup, which can be found in the JED or at the following link:

http://extensions.joomla.org/extensions/access-a-security/backup/1606

Having a backup copy is essential to restore a working copy of our site if a mistake is made.

Also, you may be wondering whether, later, if you install a newer version of the extension, you may lose all of the changes made. This can happen; therefore, we have made these modifications after we have finished installing the extensions we need.

But don’t worry too much about that. You won’t be installing a newer version of an extension every day. Mostly, you will install a newer version of the extension if bugs have been found or if the version introduces some features you want.

Otherwise, if the site is working nicely and there are no bugs or newer features, we don’t need to update these extensions.

Anyway, the most important thing to remember is to backup. Always keep a backup of your work.

As mentioned earlier, each one of the extensions that we are using is loading its own jQuery library, and thus makes our site needlessly load the library many times.

This makes our site download more files than are really necessary. Just take a look at the source code of your site. In the head section we can see the script tags that are loading the required libraries:


Here we can see that lots of JavaScript files are being loaded, and some of them are repeated. Surely, that doesn’t make our site load faster.

Let’s try to improve this as much as we can. We will use the SC jQuery plugin in order to load the jQuery library. With the help of a variable created by this library we can also determine if the jQuery library needs to be loaded or not.

How is this done? If we open the plugins/system/scjquery. php file, at the very bottom of the file you can see the following code:

$app->set( ‘jquery’, true );


In newer versions of the plugin this line of code seems to have been removed. However we can modify the plugins/system/scjquery. php file and add that line to it, at the very bottom, just like this:


$app->set( ‘jquery’, true );
$doc->setHeadData($headData);
return true;
}
}


This way we will be able to use the techniques we are about to show.

 

This will set a variable jquery with the value true. Our next step is to use this variable to our benefit, just like we did in the ajaxSearch module. Open the modules/mod_ajaxsearch/mod_ajaxsearch.php file. We modified this file and it now appears as follows:

$app =& JFactory::getApplication();

if( !$app->get(‘jquery’) ){
$document->addscript(JURI::root(true).’modules’.DS.
‘mod_ajaxsearch’.DS.’js’.DS.’jquery-1.3.2.min.js’);
}


First we need to get an instance of the global application object. We will then use the get method to try and read the ‘jquery’ variable. If this variable doesn’t exist, it would mean that the SC jQuery plugin has not been loaded, and thus the jQuery library won’t be present.

If this happens, we will let the module load its own copy of the library. This helps us in reducing the number of times the library has been loaded.

Now we are going to look into the other extensions that we used, seeing how we can solve each situation.

Code highlight

Remember the Core Design Chili Code plugin extension? We used it to reformat some code, as we can see in the next image:

Removing Unnecessary jQuery Loads

This plugin required the jQuery library, but as the plugin itself doesn’t have the library included, another plugin from the same developers was needed—the Core Design Scriptegrator plugin. You can check it in Extensions | Plugin Manager:

Removing Unnecessary jQuery Loads

This plugins works much like the SC jQuery plugin, but for the extensions of the Core Design Chili Code plugin developers. This plugin loads the jQuery library, and some others that we don’t need, in order for the other extensions to use it.

As we are using the SC jQuery plugin, we can disable the Scriptegrator plugin:

Removing Unnecessary jQuery Loads

But hey, then the Core Design Chili Code plugin stops working. Why? We have said that the Chili Code plugin needs the jQuery library, but we are using the SC jQuery plugin to provide it. At this point we need to check the Chili Code plugin source code, so just open plugins/content/cdchilicode.php. Here we can see the following piece of code:

// define language
if (!defined(‘_JSCRIPTEGRATOR’))
{
Error::raiseNotice(”,
JText::_(‘CHILICODE_ENABLE_SCRIPTEGRATOR’));
return;
}

// require Scriptegrator version 1.3.4 or higher
$version = ‘1.3.4’;
if (!JScriptegrator::versionRequire($version))
{
JError::raiseNotice(”,
JText::sprintf(‘CHILICODE_SCRIPTEGRATOR_REQUIREVERSION’,
$version));
return;
}

if (!JScriptegrator::checkLibrary(‘jquery’, ‘site’))
{
JError::raiseNotice(”, JText::_(‘CHILICODE_MISSING_JQUERY’));
return;
}


What does all this code do? It checks for the Core Design Scriptegrator plugin. If it doesn’t find any evidence of the plugin, it raises some errors and returns.

We know that jQuery will be loaded. So we can comment the code mentioned, and the Chili Code plugin will work again.

That’s it; we have just reduced one jQuery library load; ready for the next one?


Subscribe to the weekly Packt Hub newsletter. We'll send you the results of our AI Now Survey, featuring data and insights from across the tech landscape.

* indicates required