When content won’t show
If you’ve worked with Drupal for any amount of time, and your setup is even slightly complicated, you’ll come across those time where you’ve spent literally hours pulling your hair out trying to figure out why something isn’t working.
As a quasi-system admin (simply meaning I can run my own *nix servers), there’s one thing I’ve learned, which is typically the issue the majority of the time.
Permissions, permissions, permissions!
But still, there are other things that can go wrong. Here’s my start at a debugging checklist for when things aren’t working.
- Are you running a reverse proxy server?
- NO: Go to question #2
- YES:
- Is the request being served by the proxy or web server?
- Is the returned content served from the cache? (Note: use Firebug, curl, whatever to look at request/response headers)
- Did you clear the proxy cache?
- Is the content being served cached content?
- NO: Go to question #3
- YES:
- Is it coming from a file cache? (e.g. Boost module)
- Is it coming from a memory cache (e.g. memcached)
- Did you clear any memory or file cache?
- Is the error coming from the web server?
- Have you checked the server logs?
- Does the folder or content have the right permissions?
- Is Drupal generating the error?
- Did you clear the cache?
- What module is rendering the content?
- Does it have a permissions setting?
- Is an input filter removing the content?
- Did you check the watchdog report?
I wrote this list after a frustrating few hours of trying to troubleshoot a complex setup using Views Slideshow, Views Attach, ImageCache and FileField modules.
I kept getting 403 access denied and it came down to Drupal. As is true to the permissions mention above, it was a new ImageCache preset which did not have permissions set to be viewed. Beyond that, I was using content access module and that had to allow people to view the Image content type. Turns out there are likey many more permissions for any served content than you’re initially thinking of.
So the general rule is CHECK PERMISSIONS!
Other tips & tools
These are a list of tips I’ve found useful for debugging methods for Drupal (and PHP in general)
Is there a PHP.ini setting causing it?
There are some settings in Drupal that can cause you to get the ‘white page of death’. It may be one of these or another one. Memory limit, execution time or another one.
Textmate debug snippet
Add this snippet to the PHP bundle or your own bundle. Give the name of something like “dvar” and set the scope to source.php. It’s a quick command for adding dying debug code.
echo "<pre>"; print_r (${1:variable}); die("</pre>");
Tip compliments of this site
Devel module’s dpm() function
This function may become your best friend for learning what is happening behind the scenes of a Drupal page load. While it may not working in some cases, like working with forms, it will tell you pretty much where everything is at.
Devel module’s dd() function
When working with forms and other long arrays. Look in your drupal site under File system to find the temp folder (often just /tmp). Open this document in a text editor (one that will update it’s contents when changed) and you have an output console for anything you want to see.
Devel module’s dargs() function
For those times when you’re heading into some super advanced module development (the kind when you’re passing a variable number of arguments into functions) this function provides great insight.
Check out FirePHP if you use Firebug
Devel module has support for using this handy console output for Firebug.
Drupal For Firebug
Yet another Firebug extension is this handy little module. See many of your commonly referenced Drupal data bits right in Firebug.
Check for duplicate modules
There may be the rare situation where you have more than one copy of a module being used. This has happened to me and it really sucks when you spend the time wondering why the docs says it does ‘x’ and all you get is ‘y’.
