Drupal Tips, Tricks and Gotchas

October 16, 2012

The more Drupal web projects I do, the more I keep having to solve similar issues that arise during development or reusing similar code snippets. Typically you can use Features or write a small module for a lot of things but sometimes, you just need that one code snippet or quick fix. I thought I would mention some of them here as I tend to use my blog for documentation. There is no real cohesiveness or through-line to this blog post, it's just random Drupal tidbits I pick up along the way, but don't warrant a post of their own.

Using 'drupal_get_destination''

drupal_get_destination is pretty cool, it allows you to direct the user back to the referring page after completing a form. Let's say you want to send a user who logs in back to the page they were on after clicking on a login link. You could do something like this:


<?php print l("Login", "user/login", array('query' => drupal_get_destination())); ?>

The other thing you can do is put conditions on the destination. So for example, if the user logs in from the homepage, send them to a specific node, otherwise send them to the previous page they were on:


<?php if ($is_front): ?>

<a href="user/login?destination=node/1234">Login</a>

<?php else: ?>
  <?php print l("Login", "user/login", array('query' => drupal_get_destination())); ?>

Unusable Drupal theme

During development for whatever reasons, sometimes things just go wrong and your custom theme is not showing up with a broken page. This happened to me once when I messed around with the name of my active custom default theme If you have Drush you can reset the theme back to Garland:

drush vset theme_default garland

or via MySQL:

UPDATE variable SET value='s:7:"garland"' WHERE name = 'theme_default';
TRUNCATE cache;

-- Note the 's:7' stands for the number of characters in the theme name.

"Page Not Found" errors on every page except the Drupal homepage

This was a tricky one to solve and I ran up against this issue recently while working on a client's server. The client had just set it up with the specs I sent to them. (PHP 5.3.x, Git, Drush etc…) However, once I pulled in the site via Git and sourced the database, the site looked fine after that but then clicking on any link gave me a 500 error. I checked .htaccess and that looked fine as well. It turns out there were a few issues here:

Apache needed to have a setting: AllowOverride All
PHP was not compiled against curl properly

{.styled-list}

The second issue above I am not to sure about but my client's IT department said: "I used the curl that was native to CentOS, but PHP was not locating it properly." After these issues were addressed, now clicking on any link worked fine.

Git not found after installing OSX Mountain Lion fix

Well, not a Drupal gotcha per se but it did stop me in my tracks from developing after I upgraded recently to Mountain Lion, Mac OS 10.8. It was a simple matter of adding this code to my user folder .profile file:

export PATH=/usr/local/git/bin:$PATH

Reset admin password in Drupal 7

Yep, sometimes with fooling around with your local dev, you need to reset the admin password. You can do this with a simple MySQL query:

UPDATE users SET pass='$S$Cd059Vsxc8berFeg6hspaa7ejx2bSxyUisvCbT4h9o8XIgSUtPKz' WHERE uid=1;

Essentially this resets user 1 to a password of 'password'.

or with Drush:

drush upwd Danny --password="1234567"

The format for the above is basically update the user name with a new password of 1234567.

Test your Drupal site on your client's server well before it goes live!

Yeah, this was a very tough lesson learned recently. The bottom line is, if the final destination of your Drupal site is not on a server you manage and you're not familiar with it, test your site on the foreign server early and often, don't wait to the last minute to transfer your site before it goes live and expect everything to work perfectly. In this particular instance, the client also had a proxy server so what looked fine on my local dev did not on their server. It ended up being a nightmare to deal with this and in the end the client somewhat conceded that they had many issues with their proxy server that would not be fixed anytime soon. The list below are all sort of basic things but it can't hurt to check.

Make sure SSH and Git are working ok
Make sure you have the proper write permissions.
Clone your site in via Git and make sure it works. Can you click on links and do they work?
Be sure you have access to your client's MySQL with correct permissions
Test, test, test, especially if the client has particular needs for browsers like IE 7 and 8. In fact from now on, I am writing in my contracts what browsers the site I develop will be compatible with.