Drupal Scars

This is a fairly eclectic list of Drupal "gotchas" and, ideally, their solutions. What is posted here are issues that were not found on the main Drupal sites but encountered nonetheless. If this list gets sufficiently large, we'll add more organization - for now it is a catch-all.

• Major Rev upgrade (i.e., from 5.x to 6.x) causes .../update.php to run the installation process

  Problem: After you have backed up your files and your database, moved the new code into place, running the update.php process redirects to the installation screen. This is also true for multi-domained sites.
  
  Solution: Don't forget to copy the sites directory back into the "production" file hierarchy. Major upgrade releases often over-write/wipe/whatever the sites/ directory, so the update.php script (rightfully) determines this is a fresh install.

• Site's admin pages run incredibly slow (with "check for updates" module turn on)

  Problem:When doing multiple package upgrades, the admin pages take several minutes to load.
  
  Solution: During multiple package upgrades, it is best to temporarily turn off the "updates check" module. This is especially true for sites that have lots of modules available, regardless whether they are active.

• For some reason, the "?q=" string in links is gone, links are broken

  Problem: While fiddling around(&trademark; a technical term), links don't have "?q=" after the domain name suddenly and they fail. Many of my links use these (insert moral indignation of hard-coding relative links here) and now are suddenly broken.
  
  Solution: Check to see if you turned off clean URLS (visit /?q=admin/settings/clean-urls and change the enable/disable option.
  
   
  

• I have to log in twice sometimes / I get "Access denied" on login, but then it works ok

  Problem: If you initially access the site via one name (say, a short name on your network like "support" instead of the fully qualified domain name "support.wonkavision.com"), the system's cookie domain may get confused if Drupal's domain name (set either in the DB setup during install or in the settings.php as $base_url don't match.
  
  Solution: Several, none of them as graceful as an elusive "right" solution. Obvious solution is to use the FQDN, both in the setup and in the references/URLs. For multi-domain sites, you can also link the alternative site names within the /sites directory to point to the right place. Delving deeper into the server side, you can play games with hosts, DNS, etc. all of which are various means to the same end: reconciliation between the domain passed/parsed in URL and the expected domain within Drupal's view.
  
  
  Follow-up Question: What is FQDN, is that a module?
  
  Solution: sigh. No, just an acronym that only me and the guy that taught me Unix a million years ago seem to know. FQDN - Fully Qualified Domain Name. It just means use the full name of the system (recipes.wonkavision.com) instead of the short name (recipes).

  
   
  

• I don't want the login box to show up on the main screen but I need to be able to log in somehow....

  Solution: You can always get to the login screen by visiting www.wonkavision.com/?=user/login. How you choose to get there (add a link off the Primary enu, add a link in the header, footer or just keep it in mind if you are the only one that will be logging and and don't actually need a "public" way of logging in.