Fix Errors Whenever Possible

Although hiding error messages is important from a security perspective, errors and warnings mean that something isn't working correctly, and that could likely have a negative effect on your site.  It's best to try to fix them to fix them if you can (especially if they are in your own code), or for third-party contrib modules, report them to the module or project owner.

PHP Message Types

PHP, which Drupal runs under, can generate three types of messages:

• Notices - Something to be aware of that you might want to do differently, but probably won't keep your site from working.
• Warnings - More serious issues than Notices, but are not keeping your site from running.
• Errors - A serious issue that has caused the site code to stop running before reaching a normal completion.

In short, errors are problems that have to be fixed, because they are impeding use of your site.  Warnings and notices ought to be fixed, but notices may be things that you have a reason for doing in an unusual way.

Drupal 7+ Message Settings

To change the way your Drupal 7 or 8 site shows PHP messages, go to the  Configuration -> Development -> Logging and errors (admin/config/development/logging) administrative control page.

The recommended settings for a live, production site are:

• Error messages to display: None. 
• Database log messages to keep: 100 (unless you need a longer audit trail)
• Note: Do not enable the core syslog module if you are using OIT hosting.  According to the syslog module's documentation, it is not appropriate for shared hosting.  You should be able to find most useful debugging information by looking at the error logs, as described below.

Error Logs on OIT Web Hosting

If using OIT Web Hosting, you will find a record (or log) of errors the server is tracking in your Plesk control panel.

From the main panel, go into the Logs section and look for the log file called "error_log". You can either view or download this file, which lists detailed error log messages.

Other forms of web hosting will have their own logging areas where you can look for error logs.  Check with your server administrator to find out where the logs are on any non-OIT server that you might be using.

One thing to keep in mind is that server error logs will only contain messages from PHP.  Any messages generated by Drupal itself will be found in the Drupal Error log, found in the administrative area of your site under Reports -> Recent log messages.

Sample Error Messages on Web Hosting

Here are some examples of error messages you might find in your hosting log:

[Mon Jun 15 03:01:53 2014] [warn] RSA server certificate CommonName (CN) `hosting.gatech.edu' does NOT match server name!? 
[Mon Jun 15 08:52:25 2014] [error] [client 130.207.000.00] File does not exist: /var/www/vhosts/mysite.gatech.edu/httpdocs/favicon.ico, referer: http://mysite.gatech.edu/node/77 
[Mon Jun 15 09:03:20 2014] [warn] [client 130.207.000.00] mod_fcgid: stderr: PHP Warning:  chdir(): open_basedir restriction in effect. File() is not within the allowed path(s): (/var/www/vhosts/mysite.gatech.edu/:/tmp/:/usr/share/pear:/var/cache/hg:/opt/atomic/atomic-php55/root/usr/share/pear) in /var/www/vhosts/mysite.gatech.edu/httpdocs/custom-file.php on line 88

If using the "Database logging" module in core, be sure to keep only a small number of entries (1,000 seems reasonable).

Until we have a solution that can feed syslog information from Drupal into regular system logs on OIT Web Hosting, we use the "Database logging" module in core to track errors, logins, and other system messages. This module stores its logs in the watchdog table.

It is important to set this module to only keep a small number of log entries (such as 1,000), so that our database servers don't get overwhelmed.  You can change the settings for your Drupal 7 site at: Configuration -> Development -> Logging (admin/config/development/logging).

It looks like there's a bug in Drupal 7 where, if you ever turn on and activate the Statistics module (enabling the logging of accesses to the database), and then decide to turn off the Statistics module, Drupal keeps on logging to the table that it creates (accesslog), and cron never clears anything out of that table, so it can just keep growing indefinitely.  On a busy site, this can result in multiple millions of entries in that table.

Here's what you can do to check for this condition:

1. If you know how to use something like phpMyAdmin to examine your database, look for an accesslog table (it may have a prefix on it, depending on how your copy of Drupal was set up).  If it exists, then your site has Statistics turned on, or did at some point in the past.  If the number of rows is huge, then you probably need to do the next step.
2. If you know you need to fix this problem, or if you don't know how to use phpMyAdmin, you can do the following:
   1. Go into your Drupal site and turn on the Statistics core module.  
   2. Next, go to Administration -> Configuration -> System -> Statistics and look at the settings there.  Disable Enable access log, set Discard access logs older than to '1 hour', and then save the configuration.  
   3. Finally, go to Administration -> Reports -> Status report, and initiate a manual cron run to clear the accesslog table.  Note that this may fail to complete if you have over a million entries in the table.  If so, then you'll need to use phpMyAdmin or something similar to clear out the table.
   4. Once you've gotten past step 2.3, go back to your Modules page and disable Statistics.

Of course, if you actually want to use the Statistics module, then make sure that Discard access logs older than is set to something other than 'never', so that the accesslog table doesn't grow indefinitely.