#36006 – Akeeba Loader is undefined

Posted in ‘Akeeba Admin Tools for Joomla!’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Monday, 18 October 2021 12:25 CDT
confidant

When I visit the configuration page for Web Application Firewall I get this console error:

Uncaught TypeError: akeeba.Loader is undefined

    <anonymous> https://mysite.ca/administrator/components/com_admintools/media/js/ConfigureWAF.min.js?793dd7c80ed7108ddf4cf52175ee1053:6  
Everything seems to be loaded in the Network pane.

Custom Fields

Joomla! version (in x.y.z format) 3.10.2
PHP version (in x.y.z format) 7.4
Admin Tools version (x.y.z format) 6.1.12
Tuesday, 19 October 2021 01:00 CDT
nicholas

Do you see the file media/fef/js/Loader.min.js being loaded? If not, you need to download and install Akeeba FEF from our download page. Please note that this is eff-ee-eff, NOT eff-oh-eff.  They are different frameworks; FEF is client–side JavaScript and CSS, FOF is server–side PHP.

If however you do see the Loader.min.js file being loaded, does it appear in the <head> section of the page?

If it does not appear in the <head> section OR it has an async or defer attribute: you have a third party plugin which “optimises” JavaScript in a way that breaks your site. Worse than that, it also runs in the backend of your site where nothing like that should ever run! Remove it immediately. Also note that Joomla 3.2 and later allow developers to determine for themselves whether a script they are loading should be loaded blocking, asynchronously or deferred. Having a third party plugin assume that all scripts need to be loaded async, or deferred (either with a defer attribute or by moving the script tags to the bottom of the page) will most definitely break your site because the loading semantics are different than the ones the developer explicitly requested.

Let me give you an idea as to what is going on. Our Joomla 3 software only ever loads a tiny (919 bytes) script, Loader.min.js, in a blocking manner. This is a minimalistic dependency manager. All of our other script is loaded deferred, i.e. after the DOM is loaded and the browser has started rendering the page. All other scripts use akeeba.Loader defined in Loader.min.js telling it to run their initialisation when their dependencies have already loaded. The akeeba.Loader script checks ten times a second and does that. When all dependencies are loaded it removes its timer to prevent wasting system resources. It's a really cool piece of engineering and has the only requirement that it's loaded before any of our other JavaScript files.

There are some third party plugins which promise to “optimise” your site by doing something idiotic, like adding a deferred or async attribute to all scripts, or moving the script tags at the bottom of the <body> tag. Making a script async means that you don't know when it will load. It could be while the browser is parsing the head section, it might be while it's parsing the document body or it might be during or after initial page rendering after the DOM content is loaded. A deferred script or a script at the bottom of the page will be loaded after the browser has finished or just about when it finishes parsing the DOM. Any inline scripts or action attributes depending on those scripts will fail with an error. Since there's a JavaScript error, all execution of JavaScript is suspended. Therefore your backend is broken. That's why these plugins are DANGEROUS and should never, ever be used. Same applies for plugins which aggregate and minify scripts. Don't use them, folks, they break your sites.



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Friday, 22 October 2021 15:29 CDT
confidant

Thanks for the detailed reply Nicholas! I installed FEF and that fixed my problem.

I totally agree with your comments on avoiding the optimiser tools on back end, since obviously performance and SEO should not be your #1 concern.

I wouldn't mind exploring this issue further however as it pertains to front end. As you likely know, doing a page speed test using various online services (YSlow, etc.) will recommend optimising in the way that these performance plugins operate. So it seems there are some advantages to combining scripts, provided a) you don't break anything and b) you significantly reduce your http requests. I'm a regular user of JCH Optimizer and I keep an eye on whether javascript errors are happening. It allows fine-grained control over which scripts are included. If I am diligent in my testing would you still recommend not using such a thing?

You said "Also note that Joomla 3.2 and later allow developers to determine for themselves whether a script they are loading should be loaded blocking, asynchronously or deferred." Did you mean extension developers, or is that something I can leverage as a web designer?

Monday, 25 October 2021 01:15 CDT
nicholas

As you likely know, doing a page speed test using various online services (YSlow, etc.) will recommend optimising in the way that these performance plugins operate.

I disagree with these tools because they operate on the assumption that you have full control of the entire application stack and have a development team that knows the ins and outs of each and every static file. These tools have ZERO BEARING on the realities of using an off–the–shelf CMS, combining software from disparate developers.

So it seems there are some advantages to combining scripts, provided a) you don't break anything and b) you significantly reduce your http requests. I'm a regular user of JCH Optimizer and I keep an eye on whether javascript errors are happening. It allows fine-grained control over which scripts are included. If I am diligent in my testing would you still recommend not using such a thing?

You will ALWAYS break things with JCH Optimizer or anything similar to that. I already explained why. I am against using these solutions.

The CORRECT solution is that developers need to load their JavaScript deferred and avoid inline scripts, instead using Joomla's mechanism for passing options to the JavaScript through an embedded JSON document and retrieving them through Joomla.getOptions on the JavaScript side. This is something we worked on the past two years. It has a far greater benefit on the actual page speed.

It should also be noted that the number of files being loaded is not very relevant these days because a. browsers open 8 streams instead of 2 and b. there's HTTP/2 Push which allows the browser to receive the static media files before it encounters them while parsing the HTML.

You said "Also note that Joomla 3.2 and later allow developers to determine for themselves whether a script they are loading should be loaded blocking, asynchronously or deferred." Did you mean extension developers, or is that something I can leverage as a web designer?

Extension developers.

I would also recommend that you take a look at my article series about optimizing your Joomla site for speed: https://www.dionysopoulos.me/component/tags/tag/performance.html This article series will be retouched to be Joomla 4–specific and get published on the Joomla Community Magazine, too.

 



Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



Please keep in mind my timezone and cultural differences when reading my replies. Thank you!



Monday, 25 October 2021 10:17 CDT
confidant

Thanks—I always appreciate the input of a seasoned Joomla developer such as yourself. Spending my time simply building sites I don't always spend as much time learning about the innards of our wonderful system. I will read through those articles—definitely something that should be on the main Joomla! site.

This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!