Tutorials for Magento and Joomla! - Yireo

API-widgets do not work

In the MageBridge Settings-screen of the Joomla! Administrator there is setting called API widgets which can be turned either on or off. Turning the widgets on enables the MageBridge API when using the Joomla! Administrator GUI. For instance: If you need to enter somewhere within the MageBridge Settings the system-name of a Magento store, the API widgets will show you a dropdown-box instead of just a plain input-field. This makes it very easy to configure things in the backend.

The error-message API-widgets do not work indicates the bridge could not be initialized. The most common problems are listed here for your convenience:

1. The MageBridge extension for Joomla! is succesfully installed, but the MageBridge extension for Magento is not yet installed. Please complete all the steps of the MageBridge Installation Guide.
2. When MageBridge tries to access the Magento-end, it encounters an Internal Server Error or a strange redirect. This problem is described in the bottom of this page more thoroughly.
3. Your CURL-version outruns your PHP-version. As an alternative you can change your API-method from POST to GET, but this has downsides as well.

The MageBridge Catalog Menu does not work

If the catalog-categories are visible but the links are not working, this is probably due to the Magento URL-cache being outdated. This is not a problem of MageBridge, but a problem of Magento. Try logging in to the Magento Admin Panel and navigate to System » Cache Management. Then click on the Refresh button next to Catalog Rewrites. This will renew the cache Magento keeps of all catalog-items in relation to their URLs. Once this is done, the Menu-Item should point to the proper page again.

My Joomla! pages end up in an endless redirection

In some circumstances certain Magento settings might prevent third party integrations from working properly. By default, this is true for Magento 1.4: You'll need to modify some settings if you want use Magento 1.4 and MageBridge. After these settings are applied the integration works flawless.

These settings are listed in the MageBridge - Magento Settings guide.

Can I use the "Shop by" block?

Yes, you can. This block offers the functionality of Layered Navigation - one of the cooler things of Magento. You need to add a MageBridge - Custom Block module by using the Module Manager. Choose the type Catalog: Left Navigation.

Note that in the default Magento theme, this block only occurs when navigating through categories. If you're on another page, like the checkout-pages or the Magento homepage, the module will have no content.

Mage::app() failed

If Magento crashes with a message like Mage::app() failed, this means you probably made a mistake in your store management within Magento. Go to System > Manage Stores and check that either the Website, Store Group or Store View you're using is correctly setup and enabled.

Check the MageBridge Troubleshooting Guide for more tips on how to restore your settings.

Magento JavaScript does not work

If the JavaScript code of some Magento extension is not functioning as it should, make sure the JavaScript is not conflicting with other scripts. Use the Firefox Error Console to check for any errors.

If JavaScript is commented out in the HTML-source, make sure that the Magento host as configured in the MageBridge API matches the domainname as configured in the Magento Configuration.

Inaccessible backend

When you make a mistake in the MageBridge Configuration in the Joomla! backend, in most cases it will just make all API-calls to Magento fail. But if a redirect occurs under the Magento side, your browser will follow this redirect: Every time when you login to Joomla! (thanks to MageBridge Single Sign On) or access the MageBridge Configuration (thanks to MageBridge API Widgets), your browser will redirect you to some other pages.

The only way to solve this properly is to do a hard reset of the MageBridge configuration. If you execute the following database query through a tool like phpMyAdmin, only the Magento hostname will be emptied out, stopping the API connection:

UPDATE `jos_magebridge_config` SET value = '' WHERE name = 'host'

Magento basedir is same as MageBridge alias

If you install Magento in a physical folder "shop", it means that if you point your browser to "http://DOMAIN/shop" you will get the Magento homepage. But if you configure a Joomla Menu-Item to point to the MageBridge root (which equals a proxy to the Magento homepage), and the URL is also "http://DOMAIN/shop", you will never reach MageBridge but always use Magento instead. That doesn't make sense.

If you want to use MageBridge, visitors should never have to access Magento directly. This also means it's best to install Magento in a directory like "magento", "magedir" or "foobar". Using Joomla! SEF you can give the MageBridge webshop any URL you want, as long as it doesn't equal a physical directory.

failed to open stream: no suitable wrapper could be found

Your PHP-environment most probably doesn't have the setting "allow_url_fopen" enabled. This is required for updating Joomla! 1.5 extensions through the web. You can check by browsing within the Joomla! Administrator to Tools > System Info > PHP Information, and search that by page for "allow_url_fopen".

If disabled, it needs to be enabled. This can be either done on the global level (by modifying php.ini) or in the configuration of your VirtualHost (by adding a "php_flag" to the Apache configuration). Your hosting provider should be able to help out on this.

The steps of the One Page Checkout stay collapsed

If the step-boxes of the Magento One Page Checkout stay closed, this indicates in all cases a JavaScript problem. By using the Firefox Error Console, you can try to determine the problem, while the MageBridge theming-options give you tools to resolve this matter.

If no errors occur, but you are still unable to continue to the next step, make sure the URL of the current page matches the URLs used by JavaScript-scripts. For instance, if the Joomla! page is served through a different domain than the JavaScript, the browser security might stop JavaScript from working. Even a difference between HTTP and HTTPS could cause this problem.

Spoof browser

Magento uses various mechanisms to enhance the security of an user session. These methods can be configured through System » Configuration » General » Web » Session Validation Settings. By default, MageBridge allows you to use these security mechanisms. But the concept of Single Sign On (SSO) causes problems here. The reason for this is that with SSO both the browser (user agent) as the MageBridge application need to share the same session. This conflicts with the security mechanism of Magento.

We have seen systems where the API-method POST didn't work, because of this. Theoretically also GET could fail because of this, leaving you with no API-method at all - so the bridge is not working at all.

To work-around this, MageBridge also spoofs some of the browser-settings by default (REMOTE_ADDR, HTTP_USER_AGENT). Sometimes however this doesn't work, due to security privileges in the webserver. There are two ways to deal with this: Either turn off the Session Validation Settings in Magento (only the HTTP_USER_AGENT protection or perhaps all), or turn off Spoof Browser within the MageBridge settings in Joomla!. The last option is less recommended, because other things could stop working.

The bridge-data arrived empty in Magento

If you get this message, something fundamentals goes wrong. Most likely your CURL-library (part of your PHP installation) is strongly outdated, so the first step would be to upgrade CURL/libcurl and/or PHP.

Error with Zend_Log not being found

In the past, this error has occurred in some MageBridge environments, but all these bugs are fixed now. The error actually a second PHP error, while the first PHP-error actually contains the clue what went wrong. By adding restore_error_handler() to the top of the magebridge.php file in Magento, you can see this original first PHP-error. Alternatively, by modifying error_reporting to not log E_STRICT errors, these errors might be bypassed.