Have you ever had to contact support for a web app or a plugin to fix a problem, and the first thing they ask is for full access to your web server so they can “debug” the issue? 

This request frustrates me to no end. 

It is unprofessional, and it is lazy. 

The reason support asks for this is so they can run tests and inspect the results on your LIVE server. If that makes you nervous, it should! How can you know that they will not accidentally mess with your customers’ data? Not to mention all the privacy issues that crop up as soon as you hand your keys to a third party with no control. 

A proper way to deal with providing support for your app or your plugin is to add logs—a log file journals the activity and the data passing through your code. Inspecting a good log file will almost always let you know what the problem is and where the problem is. When a customer calls you for support, you only need to ask for the log files, not the keys to the server. 

In my experience, a good log file creates a breadcrumb trail that documents the data flow and the branching decisions in your code. Ideally, inspecting the log file alongside your code allows you to precisely follow along and determine what was wrong, without even having to run any code. 

A common mistake is to be unnecessarily verbose while at the same time not documenting the branching decisions. Silently discarded errors and exceptions are the usual pitfalls, and close second are if/else branches where only one of them leaves in a mark in the log. 

Security and Privacy

Now that you understand why log files are a must, especially in a client-server situation (like all the web applications), you need to be careful not to store sensitive data into the log file. Don’t store passwords or credit card numbers, and unless absolutely necessary, do not store emails. 

If sensitive data is required for you to be able to rebuild the data flow, make that available under a specific “log level” that is only activated on request. And in some cases, the entire log system can be activated only when trying to debug a problem. With this approach, however, you lose historical data that you need to fix the problem.

Always provide a way for an admin to flush the logs. 

Rolling Over

I am an overly enthusiastic user of log files. Simply because they work, and they speed up the process of solving problems. But there is a mistake that I kept doing for far too long. That mistake was no automatic rolling of the log files. What that meant is that the logs grew and grew until they would eat up all the allocated disk space. 

Oopsy! 

When using log files, decide when a log entry is too old and have an automated mechanism to remove those logs. Rolling the log files once a month (log1, log2, log3, etc.) and removing the very old files is a useful approach. 

If you don’t currently use log files, what is your strategy to support and debug your application while it is running on the customer’s LIVE server? I hope you will not say: “get root access and hack away until I find the bug” 🙂