The 35 point checklist to debug any PHP app

PHP-logo

You know it, I know it, we all know it. You’ve either picked up someone’s code, taken on an existing project or are coming back to an old project. It’s late, something’s gone wrong and you’re stuck with how to resolve the issue.

But it could also be Monday morning after a good holiday, it could have been a long weekend, or it could be a brand new project and you’re just lost for some odd reason. What do you do? How do you find that thread of reason that you can start to draw on to help you successfully debug your application and get it sorted out?Well, recently I’ve begun to compile a list of questions to ask yourself. Have a look at the started list:

The Web Server

  • Have you checked your web server log files?
  • Is the web server running?
    • On Linux, run: netstat -tlnp | grep httpd
  • Did it have any issues starting?
  • What is in error_log, access_log if you’re running Apache?
  • Have you attempted restarting your web server?
  • Have you checked your operating system log files?
    • Were there any errors logged?

PHP Error Reporting

  • What’s your PHP error reportingset to?
    • Is it set to E_NONE?
    • Is it too restrictive?

PHP Logging

  • Do you have PHP logging enabled?
    • Are your log calls set to the right levels – are they being filtered out?
    • Where are you logging to?
      • Are you logging to a mail server?
        • Is it configured properly?
        • Can it receive mail for your domain?
      • Are you logging to a file?
        • Is the file writeable by the web server user?
        • Is the disk it’s on full?
      • Are you logging to FirePHP/FireBug?
        • Have you allowed access for your test site?
      • Are you logging to a database?
        • Is a connection being established correctly?
        • Is the database schema created correctly?
        • Is the filesystem the database is on full?

PHP Extensions

  • What are the settings for all PHP libraries/extensions that you’re using?
    • Using SoapClient?
      • What’s ‘cache_wsdl’ set to?
      • Do you have trace and exceptions enabled?
    • Using Curl?
      • What’s CURLOPT_FAILONERROR set to?
      • What’s CURLOPT_VERBOSE set to?
      • What’s CURLOPT_DNS_CACHE_TIMEOUT set to?

Now it’s not complete, not by a long stretch and that’s intentional. I’m only kicking off the discussion to see where it goes. I want your thoughts, your opinions, your ideas. What do you do, that you think others here in the community can benefit from?

What’s that little gem of an idea, novel approach, bash script or link that you use? Drop in a comment or send a tweet. I’m keen to hear your thoughts and ideas.

If you liked what you read and would like to see more, please retweet it, or give it a like on Facebook or even give it some Digg love. And we always value you feedback and comments.

Matt's Pic About Matthew Setter

Matthew Setter, a passionate Australian, is the founder and chief-editor of Malt Blue. Follow him on Twitter at @maltblue, join in the discussion on Facebook and find out more about him on the team page.

checklists
  • http://erichogue.ca/ Eric Hogue

    I like that you start by checking the logs. I have seen to many developers struggle with bugs when the answer has been in the error_log from the beginning.

    If an application stop working suddenly, I would check if anything got updated recently.

    If you have unit tests, you should run them and see if they turn out anything. Good unit tests should point you in the right direction. Another option is to try debugging your application.

    • http://www.maltblue.com/ matt

      Eric, I completely agree. All too often, when I’m working with developers or mentoring, the error_log is completely overlooked, or there’s insufficient debugging information written out in the application — at an appropriate level. I’m beginning to wonder if it’s becoming a lost, or dying, practice.

      I also agree with your point about re-running tests to find if there’s been any regression in a recent change. Definitely one of the best ways to find out quickly. What continuous integration server do you use? I’m considering moving to Jenkins after hearing Sebastian Bergmann speak about it so highly at PHP London earlier in the year.

      Mind if I add your points about Unit testing to the list?

      • http://erichogue.ca/ Eric Hogue

        At work we do not use continuous integration yet. I have played with Jenkins and I love it. I will be giving a short presentation on CI next week at the office. Hopefully it will get people interested in it. I also wrote a blog post about installing and configuring Jenkins.

        Yes, you can add unit testing to your list.

        • http://www.maltblue.com/ matt

          Eric,

          all the best with the presentation. Hope that it goes well. I’ll check out your post on it shortly.

          Matt

        • http://www.maltblue.com/ matt

          Eric,

          How did the CI presentation go? Did the team come on board to the idea, or did you have some negative sentiment to the proposal?

          Matt

          • http://erichogue.ca/ Eric Hogue

            Hey Matt,

            It went pretty good. We need to start implementing it. But we have a long way to go.

            We had some people from the team at an other office looking at the presentation. In 2 weeks someone from there should present about Bamboo. So we will have a comparison between Jenkins and Bamboo. It should be interesting.