Quicktips

Drupal developers of every level of experience understand that a menu item can point to any valid path, such as that of a node. But Drupal beginners can receive a nasty shock when they discover — usually the hard way — that changes to such nodes can result in unplanned and unpleasant changes to menus. Specifically, one of the more annoying traits of Drupal is the way a menu item disappears when its associated node is unpublished (or deleted, i.e., unpublished with extreme prejudice). This may be old news to Drupal veterans, but people new to this CMS can easily stumble into this pitfall.

Have you ever had a client call you up saying their new website, which has not launched yet, is showing up in Google?

No matter how much you think, "we won't get crawled", those pesky search engines always seem to find your development site. Thankfully there is an agreed-upon standard for removing a website (or just certain pages) from search engines called the robots.txt file.

An earlier DrupalEasy Quicktip presented a technique for enabling a large number of checkboxes on a Drupal administrative page — such as the permissions admin page — using the Check All extension for the Mozilla Firefox browser.

Every Drupal site I build involves at minimum two environments: one is on my laptop, which I call the local server; another is what most people call the production server. Drupal has a very straightforward way of allowing you the developer to use a single code base to run both environments, even though they are on different machines, in different corners of the world, with different passwords, etc.

Experienced programmers know the many benefits of using descriptive identifiers, such as the names of variables and functions. Descriptive names make it easier for the original developer — and all who follow — to understand the intent of the code, and to make global changes with minimal risk. In Drupal, when creating a new content type, the site developer assigns a human-readable name (which may consist of alphanumeric characters and spaces) and a computer-readable name (which may consist of lowercase letters, numbers, and underscores).

Every so often, when migrating Drupal sites to other computers, I notice that themes become disabled. Whatever the cause, disabled themes cause bunches of problems, and my big problem today happens to be with Skinr.

If you are trying to edit settings in Skinr, for example settings on a block, Skinr only shows you those options based on the currently enabled themes.

To get the Skinr block settings fieldset back, visit your admin/build/themes page and make sure at least one theme (like your default theme) is enabled.

Let's say you have a CCK Imagefield you'd like displayed in a sidebar instead of the main $content area of your page. You can check exclude under Display Fields for that content type, and then use Views to pull out the field and stick in a block display, but if your node does not contain an image, you may notice that a few empty <div> tags are returned, and your theme might not be too friendly in this case. Now you need to find some way to hide that view if the field is empty...

Why not try adding a filter to the View?

We love Drush, Drupal's all-purpose command-line tool, for people who can't stand checkboxes. It's fast, efficient, plays nicely with Version Control Systems like CVS, SVN and Git, and even cleans the kitchen sink. However, after moving our DrupalEasy.com site to a new server we encountered a minor snag. When trying to run even the simplest of Drush commands, we were faced with the following error:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 311296 bytes)

A friend recently came to me with the following question:

I have a site that has a mode optimized for low-bandwidth use. Can I change the number of rows returned by a view based on the theme?

The Views 2 API has a function called hook_views_query_alter() which allows you to modify the View object before it pulls the results from the database.

In order to use views hooks, you must create a module that registers itself as using the Views API:

Working on an old Drupal 5 site (I was upgrading core), I came across a very odd bug. Every time I submitted a form, I was being redirected to the frontpage of the site. I had recently installed Path Auto and Global Redirect, so I thought one of those could be causing the problem.

With Global Redirect on, when I tried to visit a normal URL with an alias, in this case, node/2 that was aliased to services, I was also getting redirected to the home page.

On some of the Drupal administrative pages, you will encounter a great many checkboxes. This is especially true of the permissions page (User management > Permissions), which starts off with more than six dozen checkboxes for a vanilla Drupal 6 installation. Add a typical suite of contrib modules, and the number of checkboxes increases substantially. As a consequence, you may be forced to manually check or uncheck long sequences of checkboxes, which quickly becomes tedious and time-consuming.

Sometimes page caching can get in the way of your site's functionality - even for anonymous users. In those rare cases where you don't want page caching used, there's a module that allows you to exclude certain pages from being cached.

The Cache Exclude module has a simple configuration page where you can enter paths and pages on your site where you don't want caching to occur.

It's a great and simple solution to a sometime annoying problem.

While Imagecache is a stellar tool to automatically create and display resized and cropped images on your site, sometimes a bit more control is necessary.

Imagecache cropping is an automatic process that crops from the center of your image. So, if the most interesting part of your image is in the upper-left, it will most likely be cut off at least partially in the resulting image.

Ever downloaded a module and noticed several obvious bugs? Often, you can look in the issue queue for a module and find fixes, code patches, and help with these problems. For certain modules, the maintainer of the code may not respond - he or she may no longer be developing with Drupal, may have changed his or her email address, or any number of other factors.