Enabling Drupal 7 'www' Redirection on a Local Host

Drupal 7's HTTP access file, .htaccess, contains some URL rewriting code for redirecting all site visitors to the domain name starting with "www.", in case they try to go to the domain name without the prefix. For instance, you might want all visitors to go to www.example.com, and never example.com, for SEO purposes.
This is achieved by uncommenting the code on lines 81-82:

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
This works fine when used on a remote server, but not on a local server that is not set up to handle the prefix. For instance, if you have a local installation of Drupal at http://localhost/my_site/, then the rewrite code will change that into an invalid URL: http://www.localhost/my_site/
This problem can be fixed by adding the following line above the RewriteRule:

RewriteCond %{HTTP_HOST} !^localhost$ [NC]
Or, more simply, the existing RewriteCond line can be modified:

RewriteCond %{HTTP_HOST} !^(www\.|localhost$) [NC]

Filter a view based on empty Imagefield

Turns out there is no filter that asks wether or not an imagefield (or filefield) has a value. I came across this tip on Drupal.org. The recommendation was to use a relationship, and then choose "Require this relationship" to act as a filter. Pretty cool.
So assuming your imagefield is just called "Image", here is the walkthrough:

1. Add a new view of type "node"
2. Add one or more fields (I assume you want to include the image field) in the normal way
3. Click the button next to Relationships to open the dialog for adding relationships
4. From the "Content" group, choose your Image field (which will be followed by "fid")
5. Make sure you click the "Require this relationship" box when adding the relationship

That should be it!
I don't know if this changes for Views 3.x and Drupal 7, but this is the only way to do this in Drupal 6 and Views 2.x. You're welcome.

I can't log in to my Drupal site - every page says "access denied"

Once upon a time I updated a Drupal site and was unable to log in after the update was complete. I tried messing with the $cookie_domain and $base_url to no avail. When I used the Web Inspector or Firebug to view my Cookies I noticed I was not getting a familiar PHP Session Cookie.
Here's how to check:

1. Chrome or Safari: right click and Inspect Element, then switch to the "Resources" tab, click "Cookies" then the domain name of your site, like "drupaleasy.com".
2. Firebug: Open Firebug, click the "Cookies" tab (you may have to enable it first) 
3. Firefox: Open the "Developer Toolbar" (shift+F2 or Tools > Web Developer > Developer Toolbar) and a small black bar appears at the bottom of your window. Type:
   cookie list
4. All of the above: Open the Javascript Console and type: document.cookie

Make sure you can see a cookie that starts with SESS. Try to log in and look again.
If you don't see one, sessions are likely messed up. Try truncating your session table in your site's database.
From the sql command line:
truncate table sessions;
Everyone who is currently logged in will be logged out, but in my case I was now able to log in. Hope that helps.
If you use a graphical tool like phpMyAdmin, you can truncate a table by clicking on the box next to the "sessions" table and choosing the "Empty" option.

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.