Solving Drupal Problems With Error Logs

drupal errors

Have you ever seen an error on your Drupal site that says:

“The website encountered an unexpected error. Please try again later.”

There are over 700 people who have reported the same problem on the forums.

If you have this error or similar errors and are thinking, “OMG! Now what?”, then hang tight.

We’re here to help with this tutorial. We’ll show you how to diagnose and solve errors that appear on your Drupal site.

Print Errors to the Screen

If you see an error with no information or you see the White Screen of Death (WSOD), one of things you should do is start looking for errors.

To make errors visible on your Drupal website, find the index.php file in the main directory of your site. Open index.php and add this code directly before the very first line of the file:

error_reporting(E_ALL); ini_set('display_errors', TRUE); ini_set('display_startup_errors', TRUE);

In the example below, I have an error with the Weather module. I have deliberately loaded the Weather module to one of my test sites in an unconventional way and broken the code in an effort to trigger an error:


This error tells me that something is wrong on line 629 of weather.module. Of course, if this was a production site and errors were not enabled to print to screen, a WSOD would send me running to my error logs to see the same message.

(As a side note, it is not common practice to upload the weather-7.x-1.5 directory and it had nothing to do with triggering an issue.)

Find Your Error Logs


Let’s assume you got a WSOD and need to look at your error logs. I am not a server expert but I can tell you where my error logs are located. As you can see from the screenshot above, my error logs are at the same level as my html directory. The html directory is where your Drupal files and directories are stored.

View the Errors


The control panel I have on my server allows me to check a box and click edit, as shown in the screenshot above. If your server doesn’t have this feature, download the error log file and view it locally.

As you can see, it’s telling me the line 629 in weather.module has an issue. It also says it can’t find a favicon.ico file. Hmmm. I’ll have to fix that. Anyway, now that I know where to look for the problem, I can open weather.module and see what might be wrong.

Restoring Your Site


Some issues are triggered when a user lands on a specific page while others seem to affect all your pages. If for some reason, you can’t reach /#overlay=admin/modules or /admin/modules and disable the problem module, try the following.

  1. Launch PHPMyAdmin. I can access it by going to my If that doesn’t work, ask your service provider for help.
  2. Select the database .
  3. Click on the browse icon for the System table.
  4. Locate the record with a path to your module. In this example, the path is sites/all/modules/weather-7.x-1.5/weather/weather.module.
  5. Click the little pencil icon to edit the record.
  6. Locate the status and observe the value is 1.
  7. Change the status value to 0.
  8. Click Go.
  9. Return to your site and refresh.

You should be able to access your site again. If you go to the modules admin page, you will see the module is disabled. If you go to the Uninstall tab, you will see that it is waiting to be uninstalled. If you uninstall the module via the Drupal admin interface, the module directory is still on your server and still available to enable again.

Now that you have your site back, your next step is to resolve the problem so that you can use the module.

Opening a Module File


Because the line number is a clue to where I will find the problem, I have down loaded the weather.module and opened it in Notepad++. You could use any code friendly application that shows line numbers. I scrolled down and found line 629. As you can see from the screenshot, there is a rogue <?php tag. Of course, I put it there to break the module so I could do this demo.

Finding or Reporting the Issue


If this had been a real issue, after I restored my site and investigated line 629, I would have returned to the project page on and searched the issue queue. The probability that someone else has posted the issue and possibly a fix is high. There could be a patch waiting for me. If you need help applying a patch, check out

If there isn’t a post in the queue yet, create one. Be sure to include the error message.


In this blog, we went from a vague error message to a solution. The trick to surviving the world of content management systems and error messages is to know where your error logs are located and look at them. I can’t tell you how many times I have come across an issue, looked at the log, and scratched my head. Not all errors are easy to interpret. That’s where a great hosting service is your friend. I create a ticket and ask, “Can you help me understand what’s wrong and how to fix it?” If the error has something to do with a setting on the server, the server guys will be able to help. In our example, my server guy would have told me to seek out the coder of the module.

Happy debugging!


0 0 votes
Article Rating
Notify of

Newest Most Voted
Inline Feedbacks
View all comments
10 years ago

When suggesting to manually disable a module by setting it’s status flag in system table to 0 wouldn’t it be necessary to throw in a word of caution to check for other modules that are dependent on it?

10 years ago

Everything after “Open index.php and add this code as the very first lines of the file:” is lumped into one very long blob, apparently malformed “code” display box. Happens on both (current) Firefox and Chrome.

Completely unreadable. Did you look at the page after publishing it?

10 years ago

Sorry @Unreadable. As the previous comment shows, the article was well formed.

My fault for the mistake – editing error broke the code snippet briefly.

10 years ago

@steve, thanks for fixing. A useful article with good info, thanks!

8 years ago

Mostly this error comes from an uncatched PHP exception. I found also how to solve here:


6 years ago

Thank you so much. After banging my head againsts the wall, I found this site and it has solved my Drupal problems!

5 years ago

Drupal 7 Site Crashes Many Times
I’ve had a site running on:

Drupal 7.59
Database system MySQL, 5.7.22-0 ubuntu 16.04.1
PHP 7.0.30
PHP memory limit 128M
It has crashed many times due to the running out of memory problem. Besides, this problem started a month ago.

Another problem is in the cache database table (cache_menu), keeps growing bigger every time a when pages are loaded.
Even if I change the “Expiration of cached pages” from the performance menu to 1 hour, the cache can become huge, which leads to major memory problems.
Is there a way to safely disable cache_menu?

But I’m not sure that the only reason is the cache menu.
What could be causing this and how can I fix it?
Any advice much appreciated.

Would love your thoughts, please comment.x