Tutorials for Magento and Joomla! - Yireo

Solving 500 Internal Server Errors

A common error in some hosting environments is the 500 Internal Server Error. It hides the actual PHP error, and tells you to contact the system administrator. This tutorial helps you to solve these errors.

What happens?

Every time that a 500 Internal Server Error occurs, you should take the guidance in that error literally: You should contact the system administrator of the hosting environment to report the real error to you. Internally something went wrong, and as long as the real error is not fetched, everybody will be clueless.

These types of problems specifically occur in hosting environments that use some kind of CGI-interface to PHP (CGI, FCCGI, FastCGI, suPHP). It could be that something went wrong on the configuration-level, but it might also be that PHP encountered some kind of PHP Fatal Error. In all cases, fetching the actual log from the logfiles is vital. Note that - unless you have root-privileges - it is likely that you don't have access to these log-files. Therefor, contact the hosting provider.

Make sure errors are logged

Not all hosting environments are actually prepared for logging errors - it sounds stupid, but is sometimes configured as such for ridiculous reasons like saving disk space. The following PHP-settings are a good start for logging:

log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED
display_errors = On 

Note that these settings might be bad in production environments. After debugging, it's best to restore the original settings.

Wrong file permissions

One common cause for a 500 Internal Server Error are the file permissions of PHP-scripts. In general, all files for MageBridge should have the same file permissions as the other Joomla! files and/or Magento files. A 500-error might be thrown if the file permissions are considered to be dangerous: The execution bit should never be used on PHP-files (755 or 777 or something alike), but some servers also object against the PHP-file being world-writable (666 or 777). File permissions like these can be set either through SSH or FTP.

A lot of times, Magento is causing headaches here, not Joomla!. In general, if the Magento application works, you should apply the file permissions of Magento's index.php also to the MageBridge magebridge.php and magebridge.class.php files. In almost all cases, the permissions 644 are perfect. This means that the owner has read-write access, but everybody else has read-access only. Also make sure the Magento file js/index.php has the same permissions.

Changing the permissions for the MageBridge files will solve the problem once, but when you update MageBridge again and again, you might notice that Magento keeps restoring the original (wrong) file permissions. To solve this, you might want to change the Magento index.php to change the default umask() into umask(0022):

umask(0022);

This will make sure that new files are created with permissions 644 and new folders are created with permissions 755.

Low PHP memory limit

Another common cause of PHP Fatal Errors that again might generate Internal Server Errors, is that the PHP memory limit (memory_limit) is too low. You should make sure your Joomla! site and Magento site meet up with the minimum requirements of MageBridge.

How you should modify the PHP configuration accordingly, again depends on the hosting environment and you should contact your hosting provider about this. It might be that you can add PHP-directives to your htaccess-files, but it might also be that you need a separate php.ini file somewhere.

Other causes

For other problems, you need to access the PHP-logs or Apache-logs to fetch the actual error. In most cases, you need to contact your hosting provider for this.