I think that one of the best ways to stay current with whatever tools, languages, etc. that you’re working with is to take a look and see what other communities are doing with their tools.

For what it’s worth, I also think that bringing experience from previous projects and/or jobs to new projects and/or jobs is important – you get a chance to continue doing all of the things that worked well, a chance to avoid the things that didn’t work, and a chance to discover a new set of things that work and things that don’t.

One of the more popular tools to come out as of late is Docker. There are a lot of really cool things about it, and there are a lot of articles already being written about it. I recently read one that struck a chord with me and with WordPress-related development.

Especially this quote:

Logging is a critical part of running an application. It’s often undercooked because it’s been here for so long no one think about it anymore. But trust me, when things stop logging, admins start crying.

Is Docker Ready For Production?

Yes, it’s a good read for anyone who likes to see how other developers are doing their thing in another area of the industry and there’s a number of points made that I think many people who have been working in software for a number of years can identify with, but I couldn’t help but ask myself if I’m doing (or we’re doing) enough logging in the WordPress projects I’m (or we’re) deploying.

Error Logging in WordPress Development

Anyone who has been developing on the LAMP/WAMP/MAMP stack for any period of time is likely very familiar with Apache, MySQL, and PHP log files. Similarly, if you’re used to working with other servers and software, then the same is likely true.

Wow. Such Error. Very Confuse.

Wow. Such Error. Very Confuse.

These are software packages that have been around for a long time (well, at least in Internet years) so the data that they capture in their log file is really, really useful. I’m one of those who argue that we should all be logging errors, warnings, and notices, but I digress.

But when it comes to logging in WordPress development, are these files enough? That is, in addition to the default logs provided by the software on which WordPress sits, should we be doing a better job of logging problems throughout our code?

I see two sides to it:

1. If You Know The API…

I think that if you’re familiar with the API, then you can make a case for why you don’t really need to add any additional logging and why letting WordPress and its underlying software write to the log files is enough.

After all, at some point, you get really good at following a stack trace, identifying the line(s) that cause the problem, setting up any additional debugging, and then isolating the problem in order to fix it.

This works pretty well when you’re working in Development and/or Staging, but is it enough to do so in Production when you have hundreds, thousands, or hundreds of thousands of people using the application triggering an error or a number of errors multiple times an hour?

2. But If You Know The API…

Then again, if you’re familiar with the API, I think you can make a case for why there should be improved logging in the application beyond the standard stack trace. After all, if you know the API then you should be able to write really good logging code around potentially problematic areas, right?

Sure, a stack trace is really useful at helping to identify where the problem originates, but does it provide enough insight that we can quickly search a log, leave messages to ourselves or to other developers that help us more quickly understand what is going wrong (and possibly why?)

On the flip side, this does add a bit of extra code, require a bit of extra software (if you go with a third-party logging library), but if that improves the maintainability of the code, would it not be worth it?

Either Way

This is a conversation that I’ve had with a couple of other developers over the past year and I still don’t have an answer with which I’m satisfied.

  • Because the log files generated by the application stack are so rich and because it doesn’t require any additional effort in writing code, I often default to those.
  • However, because I’d like the error logs to be a bit clearer, easier to follow, and to make it even faster to isolate, identify, and rectify a problem, I don’t mind adding more code.

Obviously, I’m undecided – I’d like to do the latter, but I still default to the former. Regardless, I’m interested in other opinions on either side of the issue.

Category:
Articles
Tags:

Join the conversation! 2 Comments

  1. I love log files. They’re entrancing. I can’t leave them up all the time, or I’d watch them like TV, and never get anything done. I love them because I learn so much. It’s like the web site is a machine, and the log files are letting you get to see the machine run. You get to see what’s happening, and when, and why. Who’s interacting with the site, what tools they use, what they care about.

    Better logging is better info, and better info is wonderful. Never forget, knowing is half the battle.

  2. You’re right to say that PHP error logs should always be on. The issue is that they aren’t that useful with WordPress. Sure there’s plenty of PHP notice, warnings, errors that get published to the logs (especially with badly coded plugins). The issue is that they’re not WordPress errors.

    WordPress is coded defensively so a lot of application errors are simply handled internally and hidden from view. You get a lot of scenarios where a WP_Error is passed internally and the result is that nothing happened. The issue then isn’t that nothing happened. Its that WordPress had an error, dealt with it and simply didn’t do anything to alert you of it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.