Tips and tricks from the MageBridge field
Monday, 12 July 2010While we develop MageBridge and other extensions, we also take a few jobs in the field once in a while - mainly to get the practical experience out of our own extensions. With MageBridge, combining Joomla! and Magento not only gives a lot of flexibility but also requires a solid understanding of both platforms. Here are a few tips and tricks from our walk in the park.
Once upon a time there was a project
Instead of coming up with a huge compilation of unrelated tips and tricks (which you will find in our tutorial-section anyway), we only focus on one single project, we recently finished. Because the customer asked us to assist during the whole nine-yards, we were involved on all levels of expertise: Hosting, webdesign, performance, security, marketing, SEO, backoffice integration, etcetera.
A single SSL certificate ...
With Joomla! and Magento combined in one MageBridge website, you might think you only need one SSL certificate (bound to the Joomla! website). But in fact, Magento is still accessed directly when it comes to CSS, images and JavaScript. If the Magento site was served without SSL, this would result in browsers complaining.
One way to bypass that problem is by installing both Joomla! and Magento in the same VirtualHost. This way, only one domain is used, so only SSL certificate needs to be purchased. But actually we disliked this solution, because this also ment that the Joomla! security was compromising Magento and vice versa. Also, performance tweaks to Joomla! do not neccessarily apply to Magento (and vice versa), so we wanted to have separate VirtualHosts anyway.
... but two separate VirtualHosts
So the question came up: How to have two VirtualHosts with only one SSL? One solution is to have a wild-card SSL certificate that could be used across multiple subdomains. But now the cost-factor was coming into play as well. So instead, we decided to get of the Magento URL in the content being sent to the browser.
For this, we simply created a symbolic link that pointed from the Joomla! filesystem (/skin) to the original Magento folder (/skin). This required the Apache FollowSymLinks option to be enabled and PHP open_basedir to allow for accessing both VirtualHosts, but once the Magento Base URL was reconfigured to point to that symbolic link, this worked like a charm.
Performance, performance, performance
We also focussed on performance - our aim was to make Magento lightning fast. Some tricks involved changes on the Joomla! side - for example, using our own ScriptMerge plugin to bundle various CSS-stylesheets into one single HTTP request - but also changes on the Magento side: Besides enabling the Magento cache, we also enabled the Magento Compiler (new in Magento 1.4).
A lot of these performance tricks are also listed in our Site Performance Optimization (SPO) listing, while details are discussed in other tutorials.
Getting rid of MooTools, or not?
One other challenge that caught our attention was the MooTools/ProtoType conflict. Magento is using the ProtoType JavaScript framework, while Joomla! is using MooTools - and those two bite. In general, on Joomla!-only pages MooTools worked fine, but on MageBridge-pages ProtoType was loaded so MooTools caused a conflict.
Our approach was to remove MooTools first of all, which is actually the default setting in MageBridge. The site was based on the RocketTheme Mynxx template, which used a couple of MooTools-effects. But instead of getting rid of all the effects, we tried to rewrite some of them to ProtoType.
It paid off: If only MooTools was loaded, the MooTools effects were used. But once ProtoType was loaded by Magento, the MooTools scripts were replaced with ProtoType equivalents. But looking at the amount of work this costed, it was more considered to be experimental: The safest bet is either MooTools 1.2 or jQuery - both give a compatibility mode to bypass problems with ProtoType.