If you try to manually process or preview your AutoBlogged feeds and get a blank screen or it seems to hang indefinitely, that means that some error occurred but the server is configured to suppress error messages.

This occurs with hosting companies (such as Earthlink) that do not allow error messages to be shown but we also often see it with dedicated server configurations that are by default configured to a hardened state. It is definitely a good practice to suppress PHP error messages on a production server because they can reveal sensitive information about your server configuration. However, during development, testing, and deployment those error messages are necessary to identify problems. Before we can troubleshoot the issue you are having, we first need to be able to see what error message the server is reporting.

First Steps

The first thing you should do if you see this problem is to check your web root directory and the autoblogged directory for an error_log file. Some hosts are configured to suppress output errors but they will still log them to a file which you can review. However, some hosting companies also turn off error logging because these files can sometimes grow quite large (we once had a 6gb error_log file on a test server).

If you don’t have an error_log file, you might also check your hosting control panel. Some hosting companies only allow you to view the error logs through your some viewer on the hosting control panel. Finally, we occasionally–although rare–see hosting companies that output error messages as comments in the html, so it doesn’t hurt to view the source of the page where it is hanging.

PHP.INI File

If none of the above gets you anywhere, there are several ways you can enable error messages on your server. The best way is to edit the php.ini file if you have access to that. In the php.ini file there are a number of error-related configuration options (see http://www.php.net/manual/en/errorfunc.configuration.php) but these are the most important options:

• display_errors – This determines if errors are sent to the browser or not. This is the most convenient way to view error messages but this really should not be enabled on a production server.
• log_errors – This option enables or disables logging error messages to a file.
• error_log – This option determines the location and name of your error log files.

You can view the values of any of these settings in WordPress by going to the AutoBlogged support page and clicking on Show PHPInfo…

Here is a sample php.ini configuration that works well for debugging purposes:

display_errors = ‘on’
log_errors = ‘on’
error_log = ‘error_log’

The .htaccess File

If you are using a shared host or do not have access to the php.ini file, you may be able to enable error reporting through the .htaccess file. Here is a sample .htaccess configuration that will enable error reporting:

php_flag display_errors on
php_flag log_errors on
php_value error_log error_log

Note that if your server runs PHP in CGI mode rather than as an Apache module you will not be able to change these settings via the .htaccess file and you will get an Internal Server Error message. Furthermore, some shared hosting environments are configured to not allow users to set these values via the .htaccess file.

Here is a good article on controlling error handling via the .htaccess file: http://perishablepress.com/press/2008/01/14/advanced-php-error-hand…

Other Solutions

If you don’t have access to the PHP.ini file and your hosting company does not allow you to enable error messages via .htaccess, you might also want to check your hosting control panel to see if there is an option to enable error logging from there. If you still don’t have error messages at this point we actually recommend moving to a different hosting company. Our software works great with most hosting companies but if there is an error on yours and this company won’t let you see that error, we definitely suggest moving your site elsewhere.

Having said that, all hope is not lost. In WordPress on the AutoBlogged support page you can enable the options Enable logging to file when processing feeds and Show verbose debug info. This will create a file named _debug.log in the autoblogged directory that might provide clues as to what is causing the error or at least where in the process the error is occuring.

You can also open the wp_config.php file in the WordPress root directory and uncomment (remove the // at the beginning) or create this line:

define(‘WP_DEBUG’,true);

This will try to enable error messages via PHP, but may also produce a large of error messages and warnings that you can probably ignore. If you still are having problems, send us a support ticket to see if we can help. In extreme situations we may need to provide you with a unique autoblogged build where we add specific code to troubleshoot your problem.

Remember that the goal here is to find the error message or some other clue that will tell us what is causing AutoBlogged to halt feed processing. There are an infinite number of server configurations, platforms, software versions, and environment settings that can affect AutoBlogged but we can’t help much until we know where the process fails.

And finally, don’t forget to turn error messages off again (at least those displayed on the browser) when you are finished. You don’t want to be handing out information that might help someone break into your web site.

If you are getting errors that memory has been exhausted, that means that PHP is not allocating enough memory for WordPress and all its plugins to run. You can fix this by allocating more memory to PHP or to reduce the amount of memory you are using.

To allocate memory to PHP you can do one of these, depending on what kind of access you have on your server:

• Increase the memory_limit setting in the php.ini file to 48M, 64M, 96M, or higher if necessary.
• If you don’t have access to the php.ini file edit the .htaccess file in the web root directory and add (or change) the line php_value memory_limit 48M (or 48M, 64M, 96M, or higher if necessary).
• Since some hosts do not let you modify memory limits from the .htaccess file, edit the wp-settings.php file and find the line that contains define(‘WP_MEMORY_LIMIT’, ’32M’); and change the 32M to 48M, 64M, 96M, or higher if necessary.
• If this still doesn’t work you may need to contact your hosting company to see if they will increase the memory limit. If not, you may need to upgrade to a higher hosting plan or find a different hosting company.

Another alternative is to reduce the memory usage by using fewer feeds, using simpler feeds, and disabling other plugins that you might not need. Note that there are unresolved bugs in both SimplePie and PHP that might lead to memory leaks so sometimes the only solution is to use fewer feeds.