Jquery Mootools conflict

Problem Description

Some components in Joomla use MooTools, others and now the Joomla itself use jQuery. It can happen that both JavaScript frameworks are loaded. However, this often leads to conflicts because both frameworks use the short identifier $ use to be addressed. Basically, this is no longer a problem in Joomla, even if you want to use both frameworks at the same time. On the one hand, a jQuery method is commonly used noConflict () to integrate and use. On the other hand, it is necessary to load them in the correct order. This prevents conflicts in the same namespace.

But not every component or the webmaster of the site has to take care of that themselves. Joomla has already provided various methods for this that ensure correct handling. It is only important that the component that wants to use jQuery, for example, uses these Joomla methods for security - on the one hand, the integration of the frameworks via the class JHtml :: _ (...) and on the other hand the possibly necessary. Order and conflict avoidance JHtml :: _ ('behavior.framework', true) ;.

However, there still seems to be a small disadvantage, which I saw specifically when using BreezingForms forms but also with attachments: BF does not use jQuery MooTools, but wants to prevent others from using Mootools at the same time Components with the necessary jQuery comes to a conflict and therefore calls the BFQuickMode * .php in all scripts and also calls the behavior.framework () method. However, this will load MooTools, even if it is actually not being used by any component or BF. On the one hand, this is bad for performance if unused scripts are loaded pointlessly, and on the other hand, loading mootools can create a source of interference again in the first place.



So to prevent a component from loading BreezingForms MooTools uselessly, JHtml :: _ ('behavior.framework', true); and these are commented out. Unfortunately - like the BFQuickMode * .php scripts mentioned in BreezingForms - this applies to core scripts throughout. These modifications must therefore be made in the knowledge that these scripts could be overwritten again with the next component update.

An alternative would be a own plugin to program which deletes from the array of frameworks and scripts to be integrated by Joomla which are undesirable. That would be a solution that is safe from updates. I programmed such an "unloadScripts" Joomla plugin to get rid of the annoying mootools in BreezingForms.

As an attachment to this post, I have included the script for download. Please note! Use at your own risk!
Is certainly also suitable for other problem cases, especially since it can not only remove MooTools, but also any other disruptive scripts.


Similar problem in the Attachments component with modal.js and SqueezeBox

A similar problem occurs when using the Attachments or DropPics extension, which also work with the SqueezeBox as a modal popup. As soon as a Joomla post or blog is called up in the frontend when using the attachments extension, the attachment plugins also activate the function required for the frontend editor to attach documents. For this purpose, Attachments wants to open a modal window in which one could configure the document attachments for the contribution. Under certain circumstances, attachments include the modal.js script in order to be able to initialize the SqueezeBox. The following errors are typical:

ReferenceError: Hash is not definedmodal.js: 7: 7444 http://domain.de/media/system/js/modal.js TypeError: SqueezeBox is undefined

Further scripts can be used due to this error will not be executed and the website will malfunction.

Basically, attachments already make a Joomla-compliant handling of the integration of the modal box function, but somehow it doesn't really work. This handling takes place in the script components / com_attachments / javascript.php using Joomlas JHtml :: _ ('behavior.modal', 'a.modal') ;. James Cameron refers to this in his Github post https://github.com/jmcameron/attachments/issues/4 and declares the bug fixed, which it is not in my projects. As soon as you comment out the relevant line 31 in this script for Joomla 3.9.x, the errors and malfunctions disappear. Unfortunately, that would be a core script modification and therefore not a permanent solution.

The loading of the modal.js script can be prevented by my plugin linked above. However, the initialization of the SqueezeBox, which is still taking place, cannot be prevented, since it is written into the HTML as an inline script.


Link notice: This article provides very good information on the application and function of the Joomla Modal Box, especially in connection with 3rd party extensions. Further links on the topic:


Joomla plugin unloadScripts[With this plugin, unnecessarily loaded scripts (such as the Mootools framework) can be removed from the site header before the page is rendered.]4 kB
If this post has helped you and saved a lot of time, please show your appreciation: I am looking forward to a click on Google +1 and Facebook share or feedback. Show me that it was worth the effort creating your post.
Pay attention to the product advertisements (use the mouse! ;-)), because this will refinance my expenses for these contributions.