Debugging PHP code

Up until the last week debugging PHP has alwasy been something of a black art to me. Quite regularly one would get a white screen with nothing on it and not know just were to start looking for the bug. Working through the move from PHP7.3 to PHP8.4 was initially a bit daunting especially when I knew that much of my trouble would be with things deprecated and removed in the versions in between. The rant on my Blog site a few days ago probably sums things up nicely, and the update fixes is well behind on where I am today but needs proper rationalization so that rather than simply killing bugs, I am also updating the code that has the same problem in all the packages.

The starting point with all this is the PHP error_reporting setting. In the past I have preferred that this was E_ALL, that is display every error. Hiding warnings like deprecation errors is a false premise that is even more relevant when one has to skip versions of PHP. I had not appreciated that even bitweaver toggled things on and off at times which may explain why I had problems in the past, added to which both ADOdb and Smarty also hide warnings at times which might have helped to understand why there was no message at times!

bitweaver has a number of switches to control the error messages and also debug facilities. The main switch is IS_LIVE which ensures that none of the internal meassages are displayed on a live site, and also creates email messages when problems are hit. It also crudely switches between follow and no_follow which has recently been modified to allow a more refined setting such as hiding pages that only logged in users can see. Something google complains about but needs to fix at it's end! You can't search pages that are not publicly visible. It's one of the reasons I prefer a local search function so one can filter results based on who is logged in. But that is tangental to the matter in hand.

bitweavers control of error_reporting is normally set based on the build of PHP being supported such as hiding deprecated messages that have not been addressed yet. It is set in the 'defaults' config file, rather than as a site setting in config.php. Also present in config.php are switches for the Smarty engine. TEMPLATE_DEBUG switches on the titles of the templates being used in the rendered page so one can see which one has a problem. There is also a $smarty_force_compile which bypasses the cache mechanism within Smarty and always recreates the compiled php script used to then render the raw html. Something I missed a long time ago and could not understand why things did not change, although I was bypassing the check that would have automatically rebuilt it. This caching is secondary to the caching of the finished html page which bitweaver handles itself. At least there is a reload option to override that. A third debug switch is $smarty_debugging which basically switches off Smarty's own error reporting switch and allows the display of it's own internal debug messages. ADOdb has a similar switch in bitweaver, $gDebug which displays the SQL being used so one can quickly view problems. Both of these switches are a bit broad and produce lots of extra text in the browser, so being able to select what to look for by adding printout statements in the code is always much better. That is once one has a better understanding of what is going on under the hood.

The fallback print function is print_r which dumps a variable as a string of text. Crude, but essential when nothing else works. bitweaver dows take things a little further though and adds a vd function (variable display) which produces a nicely rendered grid of information which can also be opend and closed to work through multi-dimentional arrays. Something bitweaver uses a lot of. I'd not initially spotted that vd was not working on the latest stack and then I switched to print_r to get on, but I should have spent a little more time investigating. The display was handled by a 15 year old class dBug and all it needed was for the construct function which is the good old days was simply the class name ... so switch dBug to __construct and lots of stuff appeared where I'd not removed vd() tags. Took a while to go back through and clear them all. A quick check shows that dBug has not been updated since it was created in 2007, but Treedent has created a newer fork which has more display options. I can see an advantage in this approach and need to look at displaying ADOdb, Smarty and Firebird objects in the same way it handles MySQL ones. Something else for the TODO list.

This only covers the top level control of error management. Once one starts digging in to things, more of the structure of things needs to be understood. Some of the page layout stuff has been documented, and this needs expanding so I can tidy what should be core templates and what needs to be overriden in the site theme. A number of the niggles that I have been living with on the live sites HAVE been fixed in the latest code base and I am progressing well to a point where I can switch the live stack, but themes need to be tidied which I think is the next problem.

One piece of the jigsaw I had missed was that I'd changed the names of the different fpm error files to bring them in line with the rest of the 'set', but forgot to tidy the links so I've been looking at the wrong file for the errors reported direct from the releveny copy of fpm. Just been through and cleared up all four instances of PHP, although I do think I'm in a good position to drop PHP7.4 and 8.3 now that I have 8.4 working well and I CAN see the relevant warnings that still need to be cleaned up.