The development of One Theme has presented many ‘firsts’ to me. Having worked on largely corporate projects in which the code has been written to function within a particular environment, one of the largest eye openers has been building One Theme for use with not only different variations of the LAMP stack*, but also for use with differing versions of WordPress.

The release of the 2.X series of One Theme, or more specifically – One Panel has presented many issues. Much arising from the move towards an entirely AJAX driven control panel, forcing me to review all my previous JavaScript knowledge and come up with a JSON based mini framework for a standardized approach to delivering data via this medium. To this point, there have been numerous bugs in the modules that allow embedding of code due to my some minor oversight in the encoding department (duly fixed in the 2.0.1 release). The slow release cycle of One Theme has also been an issue, with customers becoming frustrated waiting for bug fixes and forcing refunds. I have decided to remedy this by offering nightly SVN builds of One Panel to the members system.

The biggest issue in resolving these bugs has been the reporting and data gathering process. Bugs occasionally get posted with little or no information that assists me in replicating the problem. I hope to resolve this in 2.0.2 by adding a test harness that will actively request that the user send the error data to our servers for investigation.

With an Ajax interface, it can be difficult to catch php errors in a usable fashion. This is where the use of PHP’s register_shutdown_function() comes in handy. We can use this method to squeeze in that last bit of functionality before PHP die’s and takes its much valued debug data with it. In this case I may want to use it to store my debug data in a database table before throwing a terminal error, or to do the aforementioned and then devliver via Javascript the relevant error data to a dynamic element on the page.

Obviously the debug harness needs to behave differently depending on which environment the code is running in. If I am loading the initial page, then the data needs to be printed to the screen before the interface is displayed – this can be done with output buffering. On the other hand if I am operating inside AJAX triggered code I need to return data via my JSON interface that can be interpreted my the JavaScript in an appropriate manner.

Its also important that the code needed to add log entries be as simple as possible, as adding entries to an existing code base on 10,000 lines is not a quick task. For this reason I have decided to use the age old:

Debug::Log( $message );
Debug::Warn( $message );
Debug::Error( $message );

I’ve also added “$success = Debug::Track( $msg )”. My implementation is rather sloppy at the moment, but I’ll be sure to post at a later date with further details and improvements as I haven’t been able to spend that much time working with this as of yet. Stay tuned!