By default, Drupal error logging happens to the log database (the watchdog table) and the screen. This is something I had overlooked for quite a while untill I stumbeled upon it while setting the error pages.
By default, Drupal error logging happens to the log database (the watchdog table) and the screen.
Error logging to the screen is quite ugly on a production site. Your visitors don't understand what's happening. It happend to me a few times on sites where I enabled page caching. The client notified me of the error messages so I disabled the caching without know I had the option to disable the error logging to the screen.
So how is this done?
The best solution for this problem is just to make sure you don't have errors in your site. That's utopia. But there's a better solution.
Go to Administer > Site configuration > Error reporting (admin/settings/error-reporting). There you have a dropdown list under 'Error reporting' with the two choices you have for the error logging, being:
The page even contains a hint to guide you in the right direction:
Where Drupal, PHP and SQL errors are logged. On a production server it is recommended that errors are only written to the error log. On a test server it can be helpful to write logs to the screen.
Just choose 'Write errors to the log.' and your visitiors won't be bugged by (to them) meaningless error messages.
Comments
You could also try using the following module - http://drupal.org/project/disable_messages - to disable specific error messages from being shown to the end user.
I write a module to grab remote image as thumbnail for my site www.webmasterclip.com,but I happen to error " * user warning: Duplicate entry '35721-node' for key 'content_id_content_type' query: INSERT INTO spam_tracker (content_type, content_id, score, hostname, timestamp) VALUES('node', 35721, 1, '120.85.36.245', 1295704620) in /home/weiqiu/public_html/webmasterclip.com/modules/mymodules/spam/spam.module on line 233.
* user warning: Duplicate entry '35721' for key 'PRIMARY' query: INSERT INTO xmlsitemap_node (nid, changed, previously_changed, comment_ratio, priority_override) VALUES (35721, 1295704619, 1295704619, 0, -2) in /home/weiqiu/public_html/webmasterclip.com/includes/common.inc on line 3528.
"
I don't know how to solve it ,but thank godness ,we can write errors to the log.
Open your my.ini ---> Mysql configuration file and change the values accordingly as given below. This fine tuning of mysql will clear the issue
port = 3306
socket = /tmp/mysql.sock
skip-locking
key_buffer = 384M
max_allowed_packet = 64M
table_cache = 4096
sort_buffer_size = 2M
net_buffer_length = 8K
read_buffer_size = 2M
read_rnd_buffer_size = 64M
myisam_sort_buffer_size = 64M
basedir=c:/wamp/bin/mysql/mysql5.1.36
log-error=c:/wamp/logs/mysql.log
datadir=c:/wamp/bin/mysql/mysql5.1.36/data
Thanks guys, really helpful content.
Mujib
I'm currently testing out some of our developers' work on my Ubuntu 10.04 laptop.
As you know, this LTS Ubuntu release comes packed with a much stricter PHP5.3 and a lot of drupal modules still need to be adapted to fix warning messages produced by PHP5.3.
Since i don't want to mess around in DB or reinstall php5.2 etc, i'm using a simple solution of adding following line at the end of my personal multisite settings.php
$conf['error_level'] = 0;
Tnx for the tip davy !
Thank You...
You can find this in the variables table. The variable is called 'error_level'.
Davy,
Bedankt ;)
At our shop-- this was a big issue, because after repeated warnings, developers failed to turn logging to screen off on production sites. I'll certainly forward the link, FWIW. (Ah, developers!)
So I'm left with 100 production sites with logging to screen on, and developers... well, who have other things to do!-- but who I can't get to go do it manually.
For 48 hours or so, I've been trying to see where this is controlled in the database. Any ideas? Hints?
mvg,
Ken
There's a site for that ;)
http://www.drupal-check.org/
Hmmm.
PHP will also typically send out warning etc (depending on your loglevel) so this setting should really be "log only" on any production site, as this is all-but-unavoidable.
Perhaps we should write a basic "go to production steps" checklist on drupal.org?
It wasn't a coincidence! PHP had a fatal warning and therefore Drupal not only didn't send the warning, it also didn't send the rest of the page. Fixed by adding
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
to index.php (very beginning of file after ?php), seeing what the error was, fixing it, then removing the above code.
I'm sure it's coincidental and indicative of another issue, but when I set this to "logs only" and hit submit, my site went down. nothing but white screens no matter what query I send.
Damn.
Thanks!
It was useful.
Thanks...I must have glanced over that in the admin menu about a million times.
Post new comment