Getting a Blank Page While Manually Processing Feeds
May 11, 2009
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.








Comment Form