When adding a field to a content type, it is tempting to create a new field, and to assign it a name so unique that it could never possibly clash with the names of fields you may create in the future (at least in that particular Drupal installation). After all, most if not all Drupal developers have examined the field tables and columns in a Drupal database — in an attempt to determine everywhere that the field data is stored, and anything else in the database that can affect it — but have been frustrated when field names are similar enough to be confusing.
We are all very familiar with the White Screen of Death in the Drupal world, AKA WSOD. One very common cause is a lack of memory for PHP - yet another is having errors turned off.
In development mode, you should probably make sure you are showing PHP errors on the screen, if this is an option. This is the kind of thing you can edit in your site-specific settings.php file, by using:
With the introduction of Drupal 7, developers may encounter a puzzling problem involving custom menus: imagine that you have created a custom menu — such as a list of secondary links for the footer of a website — and at least one of its menu items is pointing to a node. You think of an improvement to that node's content, so you edit the node and save the results. But its corresponding menu item has disappeared from your custom menu, and has somehow reappeared on the Main menu! How did that happen?
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.
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:
I recently was performing some module upgrades on DrupalEasy.com (on a development server, of course) when I was surprised to see that both the primary and secondary links were suddenly missing.
I spent the better part of two hours going through the various modules I had updated, checking and double-checking my theme, and generally pulling my hair out.
Turns out the solution was quite simple. Somehow, the sources for both the primary and secondary links had reset to "No primary links" and "No secondary links" on Drupal's main menu settings page (admin/build/menu/settings).
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.