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:
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:
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.
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?