When building web applications, especially with PHP, there are some tools that are invaluable.

These include things like a good IDE, a powerful debugger, version control, and so on. But one of the things that I think we often neglect against our shiny tools are basic text files.

No, I don’t think we need to take a step back from our usual toolset, let’s not forget files also at our disposal.

Case in point: Let’s say you’re working on a web application. If you’re using PHP, then one way to do this is to view the PHP debug log.

It’s a simple text file that gives you as much information as you could want about any page in your project.

The PHP Debug Log

Though the PHP debug log is available regardless of the type of project you’re working with. I’m going to be talking about viewing it within the context of a WordPress-based project.

Of course, right?

Since the majority of the posts that I share and work I do is in MAMP, then I’m going to approach it from that angle.

1. Activate Logging

Just in case you haven’t configured PHP to log errors, then you need to make sure that you configure that first.

From the MAMP menu, find ‘Edit Template’ and select the version for your version of PHP.

Edit Template

When the template window appears, locate the lines that contain:

  • `display_errors`
  • `display_startup_errors`
  • `log_errors`

And make sure they are all uncommented. That is, make sure they are not preceded by a semicolon.

PHP ConfigurationThis will activate logging. Restart MAMP (or Apache) depending on what you’re running.

2. Find Your Debug Log

If you’re working on a WordPress project, then you’re likely to find debug.log in the wp-content directory.


You can view this file with OS X’s Console application. Though it may be easier to peek at this file when something isn’t working as it should, I’ve found it easier to leave it open when developing.

OS X Console

That is, I leave it open along side my debugger, my IDE, version control, and my other tools. It helps to have as much information as necessary before committing code to the repository.

This doesn’t mean you’ll catch everything. I don’t. After all, it’s a lot of stuff to keep track of, but the more you make it part of your workflow, the more natural it becomes to keep it open and read it.