Drupal 7 Check for Available Updates Solution

On a Drupal 7 website's "Available updates" page (admin/reports/updates/update), if and when you request that Drupal manually check for updates (of modules and themes), it can sometimes fail to get available update data for most or all of the projects, regardless of how many times you retry the process. The problem is caused by errant records in the cache_update table in the Drupal database, which apparently are not removed by the update request. In theory, this should be fixable by requesting that the system clear all of the caches (admin/config/development/performance), but even that operation can fail to empty the table. In this case, you must empty — "truncate", in database parlance, not "drop" — that table yourself and then manually check for update data again.

Limiting Drupal Registrations to Profiles

If you are using the Profile 2 module to set up multiple profiles in a Drupal website, and you want each visitor to register any new account using only one of those profiles, then you should redirect the Drupal path "user/register" — using a URL alias or an HTTP redirect — to a new page that explains the different profiles and has links to the unique registration pages for each one. (For any profile P, the Drupal path to the profile-specific registration page would be "/P/register".) Otherwise, a visitor may arrive at the generic registration page (intentionally or otherwise) and create a new account independent of those profiles.

Drush on Mac OS X Troubles? Could be a Case Issue...

I recently discovered the solution to a long-standing drush issue I have been experiencing on Mac OS X. The symptoms of the problem included several mysterious fatal errors that would crop up from time-to-time as well as the fact that I've had to use the --uri=mysite.dev parameter for every local site on my computer.
I finally tracked down the issue to case-sensitivity. On my Mac, I keep all my local sites in the /Users/michael/Sites directory - this is the default directory that comes with OS X, and can be used by the Mac's built-in version of Apache. I use both MAMP Pro (for client sites) and Acquia Dev Desktop (for teaching), and every site I have lives in this directory.
Up until yesterday, whenever I would fire up my Terminal app, I would (by default) be deposited in /Users/michael, so my first order of business would be to do a cd sites/[directory of the site I wanted to work with]. While that worked fine as far as my Mac was concerned, when I then went to run a drush command, I would either get a fatal error (cannot redeclare a function) or drush wouldn't know which site it was in, and I'd be forced to either use a drush alias or the --uri=mysite.dev parameter. It turns out that because drush is (and most *nix-y tools are) case sensitive, it wasn't actually finding my site, hence the need for the --uri=mysite.dev parameter.
The solution is dead simple. When I fire up my Terminal app, I now use cd Sites, with a capital "S" (actually, I just set a new default directory for it). So far (less than 24 hours in), this has solved every single drush issue I had been having.

Re-ordering Views Attachment Displays

If you have a Drupal 7 view with more than one attachment display, it is not super-obvious how you can reorder the displays. When you create a new attachment display, you can choose the display to attach the attachment display to as well as the position ("before", "after", or "both").
But what if you need to attach two attachment displays "before" another display - how can you control the order of the two attachment displays.
it's actually quite easy once you know how - in the view's "edit view name/description", there is a "reorder displays" option. Click it and behold!