MageBridge Configuration Options
For your convenience, all settings of the MageBridge component in Joomla! are listed in this article. Also a short note on the settings of MageBridge in Magento can be found in the bottom of this page.
Basic Mode and Advanced Mode
Within the MageBridge Configuration page you can switch between Basic Mode and Advanced Mode. All options listed on this page are available under Advanced Mode. If you are viewing the Basic Model, some options are not available.
Tab "License"
| Licensing |
| License key |
The license key as given on the Yireo website. Without this license key, you will not be able to receive any updates. You will also need to have the same license-key in both Magento as Joomla!. |
Tab "API"
| Magento Server Settings |
| Hostname |
The domainname of your Magento installation. This should be the same as mentioned in your Yireo Licensing settings. Unless you're experimenting with Magento multi-site, this domainname also equals the same hostname under which the Magento Admin Panel is visited. Note that "www.example.com" is not the same as "example.com". |
| Protocol |
The protocol being used to access Magento through the MageBridge API. This can be either HTTP or HTTPS, while HTTPS offers more security (even without an official SSL-certificate) and is there for recommended. Actually this option is overruled by the option "Enforce SSL", so it doesn't matter what you enter here. This option will be removed in future versions. |
| Method |
The preferred method to access Magento is POST, but in some situations you will need to configure GET. Leave this setting on the default POST, unless we have indicated that it's needed to use GET. The GET-option will be removed in future versions. |
| Basedir |
The basedir to access Magento. If the URL to Magento would be something like "http://example.com/magento", then the basedir would be "magento". If the URL is "http://example.com/", the basedir should be left empty. |
| HTTP Authentication |
| HTTP Authentication |
Enable this option if your Magento site is protected using some kind of HTTP Authentication. When you enable this you need to fill in the two settings below as well. This option is not recommended for production sites. |
| HTTP AUTH type |
HTTP Authentication is available in various types. The CURLAUTH_ANY option tries them all, but if this doesn't work, you might also try to use a specific authentication-type. |
| HTTP Username |
The username used with HTTP Authentication. |
| HTTP Password |
The password used with HTTP Authentication. |
| Magento API Settings |
| API user |
The API-user as configured in Magento through System » Web Services » Users. |
| API key |
The API-key as configured in Magento through System » Web Services » Users. This key acts like a password, so feel free to enter a very long and difficult password in Magento. |
Tab "Bridge"
| Website |
| Backend |
The path to your Magento Admin Panel. Normally this is "admin", but for security reasons this could be renamed to something else. If the API Widgets are enabled, this setting is automatically detected and does not need to be filled in. |
| Website ID |
This setting refers to the Magento "Website" as configured through System » Manage Stores. With Magento you can configure multiple "Websites" and this setting allows multiple Joomla! websites to connect to the same Magento application, while still offering a different product-catalog.
The input-field here is a so-called API-widget: As soon as you have configured the API-user and API-password correctly, the default input-field changes into a select-box which makes it easier to configure this setting. If you don't use the widget but the regular input-box instead, make sure you use the numeric ID of the website - not its name.
|
| SSL settings |
| Enforce SSL |
This option allows you to dynamically enable or disable SSL. For instance, you can set this option to "Shop only" which will also make sure that all non-shop pages are served through non-SSL. The MageBridge System Plugin needs to be activated for this setting. |
| Secure URLs |
This expert-option (previously called "Payment URLs") normally should not be used at all. When the "Enforce SSL" option is set to enable SSL only on the checkout-pages (which is experimental), MageBridge needs to be instructed which URLs are secure and which are not. If the payment gateway returns a POST-request when a Magento order is placed, still nothing needs to be done here (example: PayPal). But with payment gateways that return a GET-request, the path of that return URL needs to be placed here. This counts for iDEAL ("ideal") and MultiSafePay ("msp"). A valid entry here could be: "ideal, msp". |
| Offline settings |
| Offline |
The whole webshop in Joomla! can be set offline, which basically means that the bridge is down. However, the Magento frontend is still up and running under its own URL, which gives you the option for maintenance. |
| Offline message |
When the bridge is offline, this text is displayed in the Joomla! component-area. |
| Offline exclusion |
When setting the shop offline, you can exclude various IP-addresses so you can still work on your site. |
Tab "User synchronization"
| User synchronization |
| Magento customer-group |
When a customer is created within Magento, you can determine in which group to place this new user. This setting does not effect the behavior when a customer is added from within Magento stand-alone. |
| Joomla! usergroup |
When a customer is created within Joomla!, you can determine in which group to place this new user. Note that this might contradict with the usergroup-settings in your Joomla! Global Configuration. |
| Remote Single Sign On |
By enabling this setting, users who login into Joomla! are also automatically logged in within Magento. But because Magento is never accessed directly, but always through MageBridge, this option sounds cool but is actual not relevant at all. It's safe to disable this feature. |
| User Synchronization |
With this option enabled, as soon as a Joomla! user is modified (by himself or by an administrator) the updated record will be sent to Magento, and the corresponding Magento customer will be updated as well. You most probably want to keep this feature enabled. |
| Username from Email |
This is a very tricky setting. Magento uses email-addresses to authenticate users, but Joomla! uses usernames. This is confusing, and there for MageBridge offers the option to keep the username synced with the email-address. This is probably only useful if you create Joomla! template overrides and changes in the Joomla! language-packs as well. |
| Realname from First and Last |
Joomla! does not know the concept of a firstname or a lastname. With this option enabled, MageBridge will take the Joomla! Name of a certain user, and convert it into a Magento firstname and lastname. Sometimes this gives weird results like a name "Joe -", but unless you have an alternative, keep this setting enabled. |
| Backend Authentication |
This option allows Magento authentication within the Joomla! backend. With this feature enabled, once Magento or the bridge is down, you will not be able to login to the backend. There for it might be safer to keep this setting disabled. |
| Frontend Authentication |
This option allows Magento authentication within the Joomla! frontend. Enabling this feature is highly recommended. |
| Importing and exporting |
| Customer Group |
When using the MageBridge User Export (in the Joomla! backend), set this Magento Customer Group for the exported users. |
| Website |
When using the MageBridge User Export (in the Joomla! backend), set this Magento Website for the exported users. |
Tab "CSS", "JavaScript" and "Theming"
| Because these settings allow for so many configurations, they are not explained here, but instead in the separate tutorial Theming Options in MageBridge. |
Tab "Debugging"
| Help settings |
| Show Help |
When enabled, this shows some help-text scattered out over the MageBridge pages in the Joomla! backend, useful when you're starting with MageBridge. |
| Debug settings |
| Debug |
When things go wrong, we try to help you out where possible. But a good analysis of the problem is also required. As soon as a problem can be simulated, turn on debugging. This will dump various debugging-lines per request into the Joomla! database, which can then be exported through the Logs page. This setting however is also depending on Debug IP. |
| Debug IP |
Turning on debugging will dump a lot of information in the logs. To prevent flooding of your site, requests will only be logged when the IP-address of that request is entered here. "Debug IP" can contain a comma-separated list of IP-addresses. Your own IP-address can be found just below this setting. If this setting is empty, requests from all visitors will be debugged. |
| Debug level |
Debug-messages are divided into various groups. Setting this option to All might flood your logs, while you are looking for specific things. Set this to Error if you want to leave debugging enabled for a long time. (Tip: Set the Debug IP to be empty, to log all errors from all hosts.) Set this option to Profiling to log for performance benchmarking. |
| Debug log |
Debug-messages can be written to the database, a separate debug-file or both. The database is used by default. |
| Debug console |
When using a tool like Chrome Error Console or Firebug, you can view extra messages set by MageBridge inside the JavaScript Error Console. This is primarily ment to troubleshoot which JavaScript-files have been removed by MageBridge. |
| Debug bar |
When the debug bar is enabled, various debug-messages will appear in your Joomla! frontend. The various messages can be configured with the other debug options. Make sure that your Joomla! template has a jdoc-tag of type "messages" specified, otherwise none of the Joomla! messages will be displayed. |
| Show API-segments in bar |
With this option enabled, all Magento API-requests will be logged. This allows you to visually see how much information is being fetched from Magento. For instance, when caching Magento-content in Joomla!, you'll want to make sure that this list of API-requests is actually zero. |
| Show request in bar |
When the MageBridge component is called from your browser, MageBridge will forward that URL-request to Magento. But when doing this, the URL changes slightly - the hostname is changed, Joomla! variables are stripped, Magento variables are inserted. When URLs are causing issues, this is really worth looking at. |
| Show store in bar |
Magento offers multi-site capabilities (dividing the Magento application into Websites, Stores and Store Views) and MageBridge offers numerous capabilities to load a specific store under specific circumstances. Because this can get complicated quickly, this option allows you to see which Magento store is actually loaded by MageBridge. |
| Display errors |
When this option is enabled, for the user-session that is being debugged, the PHP-option "display_errors" is activated. This allows you to see PHP Notices, PHP Warnings and PHP Fatal Errors on screen. |
Tab "Other settings"
| Plugin-events |
| Enable block rendering |
Blocks fetched from Magento can be rendered by using Joomla! plugins. This is comparable with the functionality of Joomla! Content Plugins, but only plugins of the type "magento" can apply this rendering. Normally you can disable this setting. The setting is useful if specific MageBridge fixes are applied through plugins. |
| Enable Content Plugins |
When fetching Magento blocks from the Magento theme, you can optionally parse this content through the Joomla! Content Plugins. This allows for Joomla! plugin-tags to be entered in Magento product-description, which offers many flexible configurations like linking Joomla! articles to a specific product. |
| Enable JDoc-tags |
Besides parsing Magento blocks using plugins, MageBridge can also detect jdoc-tags and translate them when this option is enabled. These jdoc-tags can be added for instance to Magento PHTML-templates. Only jdoc-tags of type "modules" are supported. |
| Advanced settings |
| Use Root Menu |
By default, MageBridge appends the Magento URLs to the current menu-item. If you want to use the MageBridge Root Menu-Item instead, enable it here. |
| Enforce Root Menu |
This setting takes up the URL of the MageBridge Root Menu-Item and applies it to any other MageBridge URL in Joomla!. While this solves the problem of duplicate URLs, it should be properly tested. Things like Menu-Item aliases are bypassed, and this setting is most likely not going to work with third party SEF solutions. |
| Enable system messages |
Normally system messages (generated by Magento) are displayed inside the component area. But your Joomla! system messages might be displayed somewhere else. This option allows you to convert Magento system messages into Joomla! system messages. |
| Enable Joomla! 404 |
By default, if Magento is unable to find a page, it redirects the user to a Magento 404 page. Because Joomla! already contains similar behaviour, it might be useful to convert every Magento 404 to a Joomla! 404. This way you only need to style the Joomla! 404-pages. |
| Backend options |
| API widgets |
The API-widgets will add GUI-elements like selectboxes and modal-boxes to the Joomla! backend, which make it a lot easier to configure things like the Magento store and selecting categories or products. However, these widgets contact Magento through the MageBridge API, and even though caching is used, this may slow things done. We recommend to leave this setting enabled at all times. |
| Advanced Mode |
Switching between Basic Mode and Advanced Mode can be done through a button in the toolbar, but also through this setting. |
| Backend RSS Feed |
Disable this, if you don't want to load the Yireo RSS-feed on the control panel of your MageBridge component. |
| Expert settings |
| Modify URL |
In almost all cases, you want this setting to be enabled. It gives MageBridge the signal to alter all Magento URLs into MageBridge URLs. Disabling this feature will lead you away from MageBridge to the stand-alone Magento site, which also disables most of the features of MageBridge itself. |
| Link to Magento |
In almost all cases, you want this setting to be disabled. When MageBridge generates its own URLs (instead of altering URLs originating from Magento), it normally points these URLs to the MageBridge component. When this option is enabled, URLs point to the Magento frontend instead, bypassing most of the features of MageBridge. |
| Spoof browser |
When you are browsing through Joomla!/MageBridge, the bridge tries to impersonate your browser on the Magento side. Because Magento introduces various security mechanisms to protect the browser session, MageBridge needs to undertake various counter-measures to fool Magento - we call this "spoofing". Sometimes a webserver does not allow this, causing the bridge to fail. In this case, you need to disable this setting and possibly lower the security on the Magento side. |
| Spoof headers |
The bridge is able to transfer any HTTP-headers from Magento to Joomla!, but some hosting environments do not allow this kind of spoofing. However, this option is needed to offer the functionality of Magento Dowloadable Products. If you encounter any bugs here, let us know. |
| Filter content |
This should normally be enabled at all times. The Magento HTML-output might contain code that causes problems within Joomla! - for instance conflicting IDs. Also, the Magento HTML might list "uenc" URLs pointing to Magento, which should point to Joomla! instead. This option allows for deep-parsing of Magento output, so that it can be properly used in Joomla!. |
| Preload all modules |
Within the normal Joomla! bootstrap, Joomla! modules are only loaded after loading the template and the component. But at that point, the bridge-request has already been sent from Joomla! to Magento, and to load the modules, a second API-request would need to be sent. To prevent this from happening, MageBridge tries to preload all MageBridge-modules. However, if another Joomla! extension (like Advanced Module Manager) performs the same trick, some MageBridge modules might be skipped while they still need to be shown. To prevent this from happening, this option can be enabled. Unfortunately this slows down Magento a tiny bit (because some Magento blocks might be loaded, while they actually might not needed). So only enable this option, if you are using a tool like Advanced Module Manager, and only if MageBridge modules are not cached and are assigned to specific Menu-Items. |
| CURL POST as Array |
By default this is enabled. Some PHP-environments have problems with this setting. Disable this only, if told so by Yireo. |
| CURL Timeout |
MageBridge contacts Magento from within Joomla! using CURL. Use this setting to configure the timeout in seconds for this connection to take place. By default this is 600 seconds. In general, if you have problems with this, you most likely need to optimize Magento, and not this setting. |
| Direct output |
MageBridge wraps Magento-pages in the Joomla! component-area. This works fine when dealing with HTML-pages, but some Magento-pages (or: URLs served by Magento extensions) might deal with JSON-content or XML-content (for instance, when used for AJAX-purposes). MageBridge tries to detect AJAX automatically, and then outputs the page in question directly. But when this fails, AJAX-output might be served within the full blown Joomla! template which is not what you want. Those URLs causing such problems can be specified here to force MageBridge to directly send their output to the browser. |
| Update format |
When upgrading MageBridge extensions, this determines whether TAR-archives or ZIP-archives are used. Some Windows environments have problems with the TAR-format, but some Linux environments experience problems with ZIP. This setting allows you to bypass bugs in your hosting environment. |
| Update method |
By default, Joomla! requires the PHP-option allow_url_fopen to be enabled for receiving updates. MageBridge can use this mechanism to receive MageBridge updates. However, MageBridge already has its own CURL-connection in place, so why not use that instead? There's no need to tune this option. |
| Performance settings |
| Enable caching |
MageBridge allows data (like blocks, breadcrumbs, headers) to be cached, eliminating the reason to access the Magento application. This can increase performance dramatically, but requires a study of how MageBridge deals with caching. Follow our online tutorials for more guidance. |
| Cache time |
The amount of seconds after which a cached element should expire. |
| Keep Alive |
When Joomla! makes a connection to Magento, it could be an idea to enable keep-alives. It might give you a performance benefit, but it might also give you the opposite. Try tuning this at your own will. |
| Encryption |
Sending data from Magento to Joomla! and vice versa, might also involve sending passwords and other sensitive data. When the API-connection between Joomla! and Magento is restricted to one server, this is no security issue, so you might turn off this option: Encrypting data costs a little bit of CPU-power, which can be skipped by disabling this option. When you have installed Joomla! and Magento on separate webservers, leave this option enabled. When using SSL between Joomla! and Magento, this encryption is automatically turned off. |
Created on Thursday, 23 July 2009
Modified on Monday, 07 May 2012
More tutorials in this section
Other tutorial sections