Working with JavaScript in MageBridge
By combining the themes of both Magento as Joomla! on a single page, MageBridge creates its own problem: While the HTML and CSS can only create glitches in the appearance of the HTML-document, conflicting JavaScript-frameworks cause the functionality to crash. Magento uses the Scriptaculous / Prototype framework, Joomla! uses the MooTools framework - and those frameworks bite. This article serves as a gathering of information for those of you willing to experiment with this JavaScript-battle.
About JavaScript-frameworks
JavaScript has grown more and more important in webapplications, it allows for better GUI-development. But though the syntax of JavaScript is basic compared to other scripting languages, it becomes more difficult to understand once you dive into more complex tasks like graphical effects.
Luckily enough, there are JavaScript frameworks which make the job a lot easier. Most frameworks are object-oriented, simple to use and shipping with lots of standard effects. The common principle shared among all framework seems to be: Write less, do more. Examples of frameworks are MooTools, jQuery, Prototype with its graphical companion Scriptaculous, extjs, Dojo, and many others.
JavaScript-frameworks are saving time
Take for instance the so-called Lightbox-effect. With this effect, some kind of content (text, photo, complete webpage) appears in a popup-box on the page, while the rest of the page is covered with some kind of gradient. This effect is heavily used in the Joomla! Administrator, which uses MooTools. MooTools makes it easier to create the graphical effect called Lightbox. Actually the Lightbox-effect has so many variations and supports so many different many frameworks, that there is even a separate project to list them all.
So what's the problem?
The problem is that all these frameworks want to make life easier. They are object oriented and use this to perform a little trick: They create a short-cut to their main core-class, which is often referred to as "renaming the namespace" - many frameworks use the namespace "$".
Next, they call the constructor-method within their core-class to identify the HTML-element you which to manipulate. And because this constructor-method returns the object itself, a second method can be appended to it as well. And because the second method again returns the object itself as well, yet another method can be appended. This procedure is known as method chaining.
$( 'my-html-element').doSomething().doSomethingElse();
Everybody uses the same $ namespace
The problem with MageBridge is that the dollar-sign ($) is used by both MooTools as Prototype as namespace. This means that the framework that is loaded as first, gets the actual namespace. The second framework doesn't, so all scripts that depend on the second framework will most probably fail.
Interestingly, the problem also occurs if MooTools is loaded twice on the same page. This does not occur with MageBridge, but might help you understand the problem.
The first framework, that is loaded, wins
In practice, if you enter the webshop on the Joomla! frontend, Magento will require Prototype to function. But if MooTools is already loaded by some other kind of Joomla! extension, this causes the Magento frontend to stop working correctly. Alternatively, if MooTools is loaded after the MageBridge headers, the extension that inserted MooTools stops working.
Detecting JavaScript errors
To know for sure that JavaScript errors are occuring - or actually to make sure in the end that they are not occurring - you should use a browser that gives you an Error Console. The Firefox browser by default ships with the Firefox Error Console, which displays JavaScript errors neatly. You can add extensions like Firebug or the Web Developer Toolbar to add more power.
Chrome also has a Console hidden away under its Developer Tools. We do not recommend troubleshooting these errors with Internet Explorer, because its debugging messages are not that easy to read.
The ideal scenario: Compatibility
The best solution would be if either MooTools or Prototype could be compatible with the other. In practice, this means that one of the frameworks would need the ability to rename it's own namespace from $ to something else. There is already one framework that has done so: jQuery, which allows to be loaded with the noflict-option:
<script src="/jquery.js"></script>
<script src="/jquery.xyz.js"></script>
<script>
jQuery.noConflict();
</script>
The downside here is that all scripts that make use of jQuery have to be rewritten from $ to something else as well.
Solution: MooTools 1.2 (no solution at all)
For now, Prototype has no plans for such a change yet, and Joomla! 1.5 makes use of MooTools version 1.1 which also has no possibility for this. But MooTools version 1.2.3 introduced something similar like the jQuery noflict-mode: The framework compatibility mode. Latest versions of Joomla! 1.5 ship with a plugin to enable MooTools 1.2, and Joomla! 1.6 ships with it by default.
While MooTools 1.2 allows you to replace the $ namespace to document.id(), other defined classes still conflict with ProtoType. Therefor, upgrading to MooTools 1.2 is not a solution to solve the conflict.
Solution: Upgrade Prototype (no solution yet)
Because Prototype is not made any effort yet for some kind of compatibility mode, there is basically no use in upgrading Prototype. However, if you choose to do this, you could still benefit from a better performance. For instance, the main Prototype-file used in the default Magento-theme is uncompressed and the effects.js file uses many effects that are not actually in use.
In the Magento wiki you can find procedures for replacing JavaScript in your current Magento theme. MageBridge offers an alternative. You can use the MageBridge settings in Joomla! to disable the Prototype-file arriving from Magento. Next, you can add your own Prototype-library to your own Joomla! template. This has the same effect, it just depends which option you find easier.
Solution: Get rid of Prototype in Magento (hard-core)
Some JavaScript of the default Magento theme could be easily left-out, just because the blocks that need it are not neccessarily needed in the MageBridge component or MageBridge modules in Joomla!. Those scripts are listed here, but disabling them in the MageBridge settings in Joomla! still needs to called experimental:
- scriptaculous/builder.js
- varien/menu.js
- varien/iehover-fix.js
Other scripts are solely used for a specific effect within the theme, but if your Magento theme uses a different effect, you will not need it anymore. For instance, on the Magento product-page you could replace the image-slider with a Lightbox-effect. Thus you will not need the following JavaScript anymore:
- scriptaculous/effects.js
- scriptaculous/dragdrop.js
- scriptaculous/controls.js
- sciprtaculous/slider.js
Solution: Modifying all Magento PHTML-templates (hard-core)
Still, you're left with the core-files of Prototype, which are also needed for various scripts of Magento/Varien itself. There are options to remove those files as well from your theme, but those options are so insane that not many of us will see this as a realistic option. Still, the options are discussed in the next chapter.
Note that these scripts only appear in the MageBridge settings in Joomla! if these scripts are actually part of your Magento theme. MageBridge fetches the headers from the theme, parses them and creates a multiple-select box from it - displaying the box in the Joomla! Administrator.
Solution: Use a different checkout-procedure in Magento (hard-core)
The default Magento theme uses Prototype, but as you're completely free to modify this theme to your own needs, you also have the option to remove JavaScript all together or replace the existing scripts with your own. If you analyze which scripts are needed for which purpose, there are in general two categories to be dealt with: First there is the category of small, nice, little effects. For instance the product-page has a nice image-slider, but also the Add to cart button uses a simple JavaScript-effect to submit the form. These all fit into the first category, which could be a listing of functionality that could easily be rewritten.
The second category is different, it's a listing of all functionality that could not be easily rewritten. The backend for instance makes heavy use of Prototype, but because we focus here on the frontend, there's basically one item in this category: The one-page-checkout. It makes use of sliding panes (an accordion) to navigate from one step to another, but it also uses AJAX to verify form-data. The whole structure makes such heavy use of the Prototype-library, that it is nearly impossible to remove Prototype.
Still, people are attempting this. An easy option here is to disable the one-page-checkout all together (Configuration » Sales » Checkout » Checkout Options » Disable Onepage Checkout). Another option is to completely rewrite the PHTML involved with the one-page-checkout, and thereby write your own checkout-procedure based on jQuery or MooTools. Certainly not for the weak of heart.
Solution: Get rid of MooTools in Joomla! (easier)
Another simpler approach is to remove MooTools from Joomla!. This could be removing MooTools from your entire Joomla! frontend, or just removing it from the MageBridge pages. As mentioned before, getting rid of MooTools by modifying the extensions is only preferred under some circumstances. If an extension is custom built or it is a template, you can probably modify it to your own needs.
Modifying modules and/or components is only recommended when no core-hacks are involved. Good extensions are based upon the MVC-model, which allows you to override the layout-file of such an extension (a template override). But the JavaScript could also be initiated outside of the layout-file, in which case a template override is still useless. Also, there are also plugins that can add JavaScript to the page. But within plugins, in general, template overrides do not exist.
Cripple your MooTools-extensions
MageBridge there for offers another option. Instead of struggling with the modification of Joomla! extensions, you can disable some JavaScript in the MageBridge settings in the Joomla! Administrator. The Theming tab allows you to remove MooTools or to customize which scripts should be removed. You can even remove all non-MageBridge scripts all together.
While these options in MageBridge are very powerful to make the Magento-theme functional again, it could also well cripple your extensions - leaving them useless. It's better to analyze which extensions need which script for which purpose.
Choosing the right ordering for the MageBridge System Plugin
Joomla! uses plugins to do things under the hood, and frequently those plugins add their own JavaScript. For MageBridge to properly detect which JavaScript-piece does or does not conflict with Magento, it is important to load the MageBridge System Plugin after those plugins. In effect, the MageBridge System Plugin should have a higher ordering-number than those plugins (using the Joomla! Plugin Manager).
But other plugins might again remove JavaScript: For instance, plugins like RokGzipper, ScriptMerge or JCH Optimize, merge various JavaScript-files into one single bundled file. But after this has happened, MageBridge will be unable to detect MooTools. Therefor, those plugins should again be loaded after the MageBridge System Plugin (by assigning an ordering-number higher than the ordering-number assigned to the MageBridge System Plugin.
Use common sense to judge what is needed, and what is needed
Joomla! is easy to use, but we have seen too many times that this ease-of-use creates the worst websites. Just because you have the option to include a full slide-show on every page, does not mean that you have to. Focussing on MageBridge, the main reason why people want to navigate through the webshop, is to check if they see something of interest or to make a purchase. So the MageBridge pages should focus on the Magento-blocks, not the rest.
It is important to note that on the MageBridge pages you need to make sure no MooTools is used. But on all your other Joomla! pages, you're free to add whatever you like. The only concern is with elements that should appear on all pages. For instance, if you need a dropdown-menu, you can choose between a MooTools-driven menu or a more generic CSS-menu. On the MageBridge pages, the MooTools-menu will not work.
Do something specific for MageBridge pages
It could be necessary to have some logic in your template to see whether the current page is a MageBridge page or not. This will enable you too make changes only to those pages where it is needed. You will need to detect whether the current pages are using MageBridge or not.
Because the whole problem of JavaScript has to do with the client-side, so the layout, we are not dealing with the MageBridge plugins, only with the modules and the component. Even better, the amount of MageBridge modules that require JavaScript without the component being present, equals zero. The only check you need to is to check whether the current page is served by the MageBridge component or not.
To check for MageBridge you could add the following PHP-code to your Joomla! template. This will only display the JavaScript if the current page is not a MageBridge page:
<?php if( JRequest::getCmd('option') != 'com_magebridge' ) { ?>
<script src="/script.js"></script>
<?php } ?>
But there's also a different option: If you copy your entire template to a new template, you can assign the original template as default for all pages, but use the template option Page Assignment to assign the copy only to the MageBridge pages. All MageBridge changes can occur one single template without the need for PHP-logic. The only downside here is that you need to modifythe Page Assignment every time when a new MageBridge Menu-Item is configured.
Removing Magento scripts on specific Magento pages
An alternative way to deal with the conflict, is to remove the neccessity for ProtoType on some of the Magento pages. While this quite hard to do in Magento itself (due to the XML-layout) you can also use the MageBridgeTemplateHelper class to accomplish the same thing. You will still need to rewrite the Magento PHTML-templates to make sure that the HTML does not refer to any JavaScript anymore.
For instance, if you would want to rewrite the category-pages, you can modify the PHTML-templates to remove all JavaScript-calls (because they are not needed there much). Then in your Joomla! template, you could instruct MageBridge to remove all Magento scripts on those category-pages. Because MageBridge will only disable MooTools when ProtoType is actually loaded, this will effectively re-enable MooTools.
$mb = new MageBridgeTemplateHelper();
if($mb->isCategoryPage()) {
$mb->removeMagentoScripts();
}
The MageBridgeTemplateHelper allows for many more tricks like this, but ofcourse you need to be experienced with PHP to play with it.
Why all this trouble?
A question that pops up so now and then is, why all this trouble? Yireo has developed a bridge, and shouldn't this bridge fix all these problems? Most of the time, these comments come from people who are used to VirtueMart and want to switch-over to Magento/MageBridge.
The important thing here to note is that MageBridge is not a magic tool that allows you to configure Magento just like any other Joomla! component. It is a bridge. It brings Magento to Joomla!, but the kind of problems that are discussed here in this article are actually very common when dealing with Magento.
The only way we could fix this problem is if we would develop our own theming engine inside Joomla! based upon data coming from Magento. Though the architecture of MageBridge allows this, this would require an immense work (which will certainly need to pay itself back somehow). More importantly, the whole frontend will no longer be supported by Magento, but a much smaller entity called Yireo. You're no longer using Magento, but a webshop called MageBridge - it's no longer a bridge, it's an application on its own - with all the risks involved.
Created on Thursday, 13 August 2009Modified on Wednesday, 07 September 2011