Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Latest post by confidant on Monday, 25 October 2021 10:17 CDT
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:6Everything seems to be loaded in the Network pane.
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 • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
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?
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 • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
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.
Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.
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!