As I’m helping a dev figuring out a broken wp theme, I came over this, imho, super-tip on howto print contents of a variable to the httpd log file.
In this particular case I’ve narrowed it down to a variable that seem to behave different between a 2 minor wordpress versions.
file_put_contents('php://stderr', print_r($foo, TRUE))
Will print the content of variable $foo to the httpd log, in my case I put that into places in the code to track content for a couple variables in the code, I added a ‘mark’ as well to easily grep it from the weblog
file_put_contents('php://stderr', print_r('Here man: $foo', TRUE));
I found this over at stackoverflow.com
Troubleshooting misbehaving php sites can be a pain.
It’s even more pain when the dev has put
hidden ‘somewhere’ in one of many, many, many php source code files .
I switched from stock Debian Squeeze php 5.3.x to dotdeb’s 5.3.10 yesterday on a lot of servers. Usually a minor upgrade shouldn’t introduce any major changes, but in this particular case I’ve come across several customers having encoding problems. It’s related to the mysql backend, which defaults to utf-8 and customers having code encoded in latin1 (iso8859-1 or iso8859-15), that is: they’ve encoded their stuff in mysql in latin1. It’s an easy fix, you simply have to specify your mysql encoding when connecting via php, f.example:
$link1 = mysql_connect('localhost','user1','pass1',TRUE);
More info at php.net
Came over this one on a stripped down, chroot’ed, shell server. The php date() function need access to files in /usr/share/zoneinfo , zoneinfo wasn’t inside the chroot so the fix was easy:
# cp -a /usr/share/zoneinfo /path/to/chroot/usr/share/