Two features of PHP that I believe are often overused when it comes to “debugging” are using echo and var_dump. I’ve talked about this in a few different articles around debugging (like in here and here).
And as much as I am a fan of using a debugger, I think it’s also important to implement a type of logging system so that you or your client can go back and review the activity that’s been happening within the system as they or their users have been, you know, using it.
There are two aspects to doing this, though, especially if you’re looking to following the PSR logging interface and they are:
- the rules for the actual logging interface,
- a project that properly implements said logging interface.
So why not tackle both in this post?
The PSR Logging Interface
The PSR logging interface (or PSR-3) covers a number of things all of which you can read about in more detail on the actual page.
- The Basics
- Helper Classes
- Log Levels
- And more.
But for the purposes of this article, I want to talk specifically about the interface itself, a project that implements it, and why it’s important.
The Logging Interface
The homepage for the documentation states:
This document describes a common interface for logging libraries.
The main goal is to allow libraries to receive a PsrLogLoggerInterface object and write logs to it in a simple and universal way.
From a development standpoint, that’s nice, right? I mean, it provides a single, consistent way that we can bet on for whatever logging library we opt to use in our projects. I’ll cover my preferred library later in the article.
For those new to object-oriented programming or simply curious as to how a consistent interface benefits us, think of it this way: Regardless of what system you choose you’re guaranteed to have a certain set of functions, states, and so on you can use in your application.
Ultimately, adding a logging system that has a standard by which it must follow provides a variety of benefits regardless of which library you choose (so long as it conforms to PSR-3).
Monolog is more or less the de-facto logging utility for PHP applications.
It’s easy to add the project via Composer but it also includes a variety of different ways to output data:
Monolog sends your logs to files, sockets, inboxes, databases and various web services. See the complete list of handlers below. Special handlers allow you to build advanced logging strategies.
Personally, I’ve used it only within the context of sending output to files; however, having the ability to output it to other systems (especially databases such as when working with WordPress) is nice. Of course, you don’t want to abuse that ability.
Secondly, it’s important to recognize that although you can instantiate the Logger within a function or another class, there are other, more object-oriented ways to do this. PSR-3 covers this (as mentioned above).
In short, you want to make sure that your class accepts an instance of a class that implements the LoggerInterface. Monolog implements said interface, so that’s no problem.
Furthermore, what happens when you have a group of related classes all of which need to implement logging?
- Do these classes inherit from a common parent?
- Do these classes implement a trait? (This is an option a friend recently presented to me.)
- Does each class simply accept the dependency via constructor injection?
There are a variety of ways in which loggers can be added to a class and it depends on how your project is organized.
More On Logging
In any case, introducing logging into an application is important for a variety of reasons such as being able to troubleshoot when something isn’t behaving as expected in both development, staging, and especially in production.