Update: You can find KLogger on github.
Since the latest release of wpSearch, a couple issues have cropped up and are slated to be fixed shortly. Some of the issues, although, are a bit harder to catch without a good set of debugging tools for PHP. The classic example of such a tool would be a log file logger.
As soon as I realized the need for a logger while developing wpSearch, I decided to check to see if one had already existed on the internet — someone had surely created a simple logging class and made it available before .. I would think. I’m a believer in the C programmer’s motto “build upon the work of others”, so checking to see if someone else has done the same thing prior to starting a project comes naturally.
After a little browsing, I couldn’t find what I was looking for. Put plainly, I wanted a logging class that:
- Checked permissions prior to logging
- Had a priority heirarchy built in ( Debug, Info, Error, and Fatal Message Levels)
- Logged to plain old text files
- Managed file handling cleanly (Open the file once, close the file once)
- Managed resources (make sure the file gets closed)
Not too complicated. This logging class would require around 100 lines of code.
Another option involved using logging functions available in Zend, or the logging class provided in PEAR. These libraries were a little overkill for what I needed, so I passed.
I decided to write of the class myself, and it has turned out to be pretty handy. I figured someone else would probably find it useful as well, so I have posted it on it’s own project page. Click here to go to the KLogger project page.
Using KLogger is very straight-forward. Here’s an example:
require_once 'KLogger.php'; ... $log = new KLogger ( "log.txt" , KLogger::DEBUG ); // Do database work that throws an exception $log->LogError("An exception was thrown in ThisFunction()"); // Print out some information $log->LogInfo("Internal Query Time: $time_ms milliseconds"); // Print out the value of some variables $log->LogDebug("User Count: $User_Count");
Depending on the priority level that is used when instantiating a new KLogger, only certain messages are actually logged to the file. If the most verbose priority level is used, ( KLogger::DEBUG ), all messages are logged. If the least verbose level is used ( KLogger::FATAL ), only Fatal-level errors are logged. Here’s a breakdown of the most verbose level to the least-verbose level:
- Debug (Most Verbose)
- Info …
- Warn …
- Error …
- Fatal (Least Verbose)
A sixth level is also available: KLogger::OFF, so if you need to release a site without logging, you can simply set the priority level to Off, and not have a single message logged. (In fact, a log file will never be opened).
There isn’t too much documentation on the class right now, but it shouldn’t be too hard to figure out.
A couple comments on design: A few log class examples I’ve seen implement a singleton pattern, essentially locking the programmer into using one logger at all times. I usually lean towards letting the developer decide those things: If he wants to use a single logger, he can create a global log object in his application.
An screenshot of KLogger:
I think at this point I’ve actually done a better job describing KLogger in this post than on the project page. A few more details are listed there, along with the download. If you find it useful, leave a comment and let me know.Follow @_kennyk_