The MageBridge System Plugin enables various core features, and should never be disabled for a MageBridge-based site. But it includes features and options worth describing. This whitepaper covers the basic workings of this plugin, and also discusses the parameters it ships with.
The MageBridge System Plugin provides various core tasks of MageBridge, and should not be unpublished. The plugin first of all loads the MageBridge autoloader - a PHP-class that makes it possible to find all other MageBridge-related classes automatically. But it also performs various other (technical) tasks. Normally, there is no need to configure this plugin. Reading this guide is therefor only recommended for MageBridge administrator who are already more experienced with the features that MageBridge offers.
Some of the features of the MageBridge System Plugin are actually copied to another plugin: The preloader-plugin. This second plugin makes it possible to load specific things very early in the bootstrap of Joomla!. In general, it is wise to load the MageBridge Preloader Plugin as early as possible (by giving it a very low ordering-number in the Plugin Manager), while the MageBridge System Plugin should be loaded as late as possible.
All options of the MageBridge Preloader Plugin are exact copies of the MageBridge System Plugin, and are listed below.
MageBridge has the ability to force SSL upon certain pages. For instance, when you enable SSL for the MageBridge checkout, you will want to know for sure that SSL is enabled, once a customer accesses those checkout-pages. Joomla! by default does not enforce it, it simply generates SSL-links, but it does not check whether the current page should actually be loaded over SSL or not.
This plugin-option makes it possible to redirect from SSL to non-SSL and vice versa. It's best to leave this option enabled. You can configure the SSL-behaviour of MageBridge through the MageBridge Configuration.
Because Magento already generates SEF URLs, MageBridge has a requirement for Joomla! SEF to be enabled as well. However, enabling Joomla! SEF does not guarantee that all URLs are actually SEF URLs - Joomla! might still contain non-SEF URLs. This option guarantees that MageBridge component-URLs are for sure SEF URLs. Once this option is enabled, and a call to a non-SEF URL is made, MageBridge will automatically redirect the browser to the corresponding SEF-location.
A simple test would be to type in the following URL and see what happens:
With MageBridge, Magento and Joomla! are combined, while both applications offer similar functionality: Both are offering a password-reset page, or a login-page, or an account-settings page. If you want to disregard the entire Joomla! com_user component, you can enable this setting and MageBridge will try to redirect all Joomla! com_user URLs to their Magento equivalent.
Within the MageBridge backend, you have the option to replace certain Magento URLs with custom Joomla! URLs. For instance, this allows you to replace the checkout-success page with your own page, or replace specific Magento product-pages with custom Joomla!-pages. This plugin-option makes sure that a browser is redirected to the corrected URL.
When saving a profile or user, it is common practice in Joomla! to generate a plugin-event, that can be used by plugins to react. For instance, when a JomSocial user is saved, MageBridge can react on that user-event so that changes are synced to Magento as well. In the past, however, some user-changes were not synced by MageBridge because JomSocial did not generate an event. This plugin-option is an attempt to fix this, but it is an ugly workaround. It is best to leave this option disabled, test things properly and notify the Yireo Team if things do not work properly.
The same as the option for JomSocial, but now for Community Builder.
When a customer logs in through one of the Magento forms, the Magento form is submitted to Joomla!, after which MageBridge will forward the POST-request to Magento. But a simple login could also be handled by Joomla! (which is actually a little bit faster). To skip the Magento authentication and use the Joomla! authentication instead, you can use this plugin-option.
MageBridge requires Joomla! SEF to be enabled, but it also assumes that Magento is able to generate SEF URLs, without Joomla! being involved. In the past, MageBridge has put a lot of work into supporting non-standard SEF extensions like sh404SEF and SEF Advance: These extensions require all extensions to generate non-SEF URLs instead, so that the SEF-extension could translate them to SEF URLs. However, the fact that Magento already generates SEF URLs, makes those extensions crazy and useless. The features of this plugin were ment as an experiment to work around this shortcoming.
At this point, MageBridge only supports SEF-extensions that actually provide backward-compatibility with Joomla! core SEF. Because sh404SEF only supports either their own SEF or non-SEF, their extension does not work with MageBridge, and this plugin-option has actually become obsolete. This option is not required for other SEF-extensions.
The Joomla! core-class JModuleHelper defines how modules are loaded by the Joomla! core. Normally Joomla! modules are loaded late in the Joomla! bootstrap, but with MageBridge, the bridge might need to be built before that. Because of this, MageBridge tries to preload MageBridge modules, by overriding the JModuleHelper class.
This is a fine clean solution, but it fails if other Joomla! extensions decide to do the same thing: The NoNumber extension Advanced Module Manager is one such extension. Luckily enough, MageBridge and AMM are compatible with each other. This plugin-option is therefor only added for developers, and it needs to be enabled for proper functioning of MageBridge.
The plugin also offers various other tricks. For instance, the plugin allows for a postlogin: Under some circumstances, when a Magento customer is logged in, the user-events of Joomla! are not triggered - but this will leave an unwanted situation where Magento labels the customer as logged in, but Joomla! will label the user as guest.
The MageBridge System Plugin also supports NewRelic monitoring: It adds a custom tracer for the MageBridge proxy, so that you can find out how long it takes to execute the API-call to Magento. If you are not using NewRelic already, note that the MageBridge debugging facility already contains some benchmarking tools.