Simpler Password Reset in Drupal 7 - Revisited and Improved

This is a follow-up to my earlier post in which I described a simple trick changing Drupal's password reset behavior. That trick emails the user a link that logs them directly into the website, instead of the default one-time login page. That one-time login page forces user to click a Log in button before they are able to change their password.

In the thread following that original post, Heine referred me to the Drupal issue in which the one-time login form was created. Now I understand better the reasons behind the one-time login form. To be perfectly frank, the solution from that thread was lazy. It solved the problem, but not elegantly, and Drupal deserves better. The user asked to reset their password so that's the form they should see, as soon as possible without the unnecessary step.

Here's what the user sees first, in core Drupal:

And here's what (I think) they should see:

This post describes how to accomplish this with a custom module. [UPDATE: Save yourself the trouble of writing a custom module by downloading Simple Password Reset module from drupal.org.]


Simpler Password Reset in Drupal 7

Here's a helpful tip for maintainers of Drupal 7 websites, if you're as puzzled by the password reset process.

For those not familiar, to reset a password you give your email to the site, then it sends an email with instructions how to reset your password. This much is reasonable and expected. Only the user with access to their email account will be able to change the password. This email comes with a link, and here's where things get weird. Typical users (and developers, too) expect that link to bring you to a page where you can change your password. Instead the link brings you to a form that looks like:

At this point, many users are scratching their heads wondering "WTF?"1 Experienced Drupalers know to click that Login button, then on the next page change their password. Not all users make it that far. In most (all?) cases, that Log in button is just one extra unecessary step in the password reset process.


Finding run-time Drupal errors in Emacs

Earlier I stumbled on a nifty compile-mode trick for emacs, and I used it to quickly jump to errors reported by coder.module. Here's another useful one, to quickly find errors and warnings at run-time.

Drupal reports PHP errors, warnings and notices to the watchdog and/or to the page. So as you're coding a new module you'll see something like this, just to pick one I recently noticed :

Warning: Invalid argument supplied for foreach() in pay_form->form_validate() (line 368 of /path/to/drupal/profiles/custom/modules/pay/includes/handlers/pay_form.inc).

This message comes from PHP, as displayed by Drupal's error handler. It's nice that it identifies the exact line of the problem. But it's not ideal that you then have to then look up that location manually. I'm always forgetting the line number by the time I open the file.

So, here's how I'm now jumping to these errors a little more easily...

Drupal Contrib Attribution and Credit with Magit for Emacs

Third-party Drupal modules, like Drupal itself, are a community effort. I maintain several of these modules, and they are made better when helpful users submit patches to the modules' issue queues.

Drupal 7 User IDs - Not Consecutive

Putting together a new Drupal site, I had a puzzling moment when I noticed a new user's ID was number 15. This was mysterious because the site had only 4 users on it. And just moments before I had created a user who's ID was 13. ID number 14 went missing, and I couldn't find it anywhere in the database.


Coder.module for Emacs Users

For Drupal developers who don't already know, coder.module is a useful helper. It helps ensure your code obeys Drupal standards, and in many cases catches potential errors before they happen. Anyone maintaining a project on drupal.org should be using it.

Here's a trick for the lucky few Drupal devs who are also emacs users. I recently saw an informative post about emacs' compilation mode, specifically how to use a custom compiler. Emacs users should already be fans of compile mode, but if you only ever use PHP, you may not know it. It is worth learning. If you know it you probably see where this is going - we're going to use coder.module as our custom compiler. Then we're going to quickly and easily jump to every error/warning in the source code using C-x `.

Rsync to Update a Drupal Website

I saw a recent post by Brandon Tate about using rsync and I wanted to share that...

a) I'm a big fan of rsync, and
b) I've used rsync for some time to keep Drupal websites up-to-date

Typically, I create a staging directory on a local machine. I check the website files out, from a source code control system, into the staging directory.


Drupal Staging Problem (revisited)

As a freelancer and Drupal specialist, I've worked with a number of website-building teams. It seems like each group reinvents solutions to the problem of sharing settings between multiple copies of Drupal. Frankly I'm not sure "solution" is the best word, because with each team, there have been headaches in setting up a new copy of the site for development, and further headaches getting changes to other developers' copies and to the live server.

This problem has been called "the Drupal Staging Problem" (in an excellent summary by Dominique De Cooman). If you ask around, you'll hear about a number of solutions, including but not limited to hook_update_N, backup_migrate.module, features.module, deploy.module, and possibly others I don't know about. In this post I describe a new(-ish) approach that I call site_update.

So many solutions! Does that mean the problem is solved? Or could it mean the problem is widespread, but not solved at all?


Drupal Imagecache 404 "Unable to Find" Tip

Here's a little tip for developers who encounter "unable to find" errors from Drupal's imagecache module...

Background: As a website developer, I often run a local copy of a website on my own server. I make and test changes there, before promoting those changes to the live website. Usually, my local copy is "incomplete" in that it does not have all the content and data stored on the live site. (Incomplete on purpose, as it would be a lot of overhead to keep all data and files in sync between servers.)

Problem: When my local copy is missing image files, pages will not look right, and I will see 404 errors in my Drupal log. This may seem a minor inconvenience, but it can actually cause bigger problems. Consider that a single page may have dozens of images. If all goes well, the server returns those files directly; but when they are not found, it's up to Drupal to server up a file not found page. As you probably know, each page served by Drupal entails all the overhead of Drupal's bootstrap process. So what is normally a single request to Drupal is suddenly dozens! This can really slow down a server. Plus, if your trying to step through code or find errors in logs, there's suddenly a lot of noise relative to the signal you're interested in.

Subscribe to RSS - drupal