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:
I was working on a Drupal migration project today using the Migrate module where I needed to import only select user roles from the source (Drupal 6) database.
The Migrate module allows for a custom query to select only the user roles that need to be imported. In my case, the two roles I wanted to import had role IDs of 4 and 6. So, how do I write a query using the Drupal Database API to do this? Turns out there's a pretty elegant answer. Rather than writing something like:
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:
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.