Quicktips

I recently made the switch from another (several) code editors to PhpStorm based on the recommendations of several members of the Drupal community - not to mention all the postive things I've heard about it on IRC and various other places.

My main motivation for making the switch was the ability to have a integrated debugger - both when running Drupal in a web browser and via Drush. While there are plenty of resources online demonstrating how to set up the debugger, I found that I needed to do a combination of things to make it happen

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.

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!

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.

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.

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:

Every so often I will find myself needing to update lots of Drupal modules but not one in particular. Perhaps I have patched the module, or perhaps there is a new version of the theme that I know will break my site layout.

Drush can save you from this dilemma, as of version 4.x - yes, it's true!

In the old days of web design, we had to put all of our files in folders, so having a path like example.com/category/sweaters/cashmere/winter-special.html was really common. You could also remove any part of the path and be sure you would get an index page, such as example.com/category/sweaters/index.html.

When building a Drupal-based website or theme, you will invariably create some test nodes of a content type that has at least one text area field. You should then add some example text, to see how those fields will look on the website. But beyond those nodes focused on styling, you may find it necessary or advisable to create a large number of additional test nodes of that content type. When you begin this process, you may wonder whether it would be best to add placeholder text (such as the venerable "Lorem ipsum") or leave those fields empty.

When working on a local copy of a site that also has a production, stage, and/or development environment on another server, it can be handy to hard-code the "Temporary directory" file path as found on admin/config/media/file-system

I know there are modules to handle this, but Rules can do it all:

If you visit admin > config > workflow > rules on your site, start a new Rule like so:

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:

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

Drupal website developers and administrators benefit from its built-in feature to periodically check if any of the enabled modules and themes are out of date. Drupal performs this check daily or weekly, when its cron job is run, automatically. If there are any modules or themes in need of an update, then on the admin area's modules or themes "List" page, you will see the notification: