While not strictly a requirement, in the interests of not having crazy URLs on your Drupal site it's recommended to set up your web server to support .htaccess files. This will let you have URLs like "/products/cool/stuff" instead of "?q=products/cool/stuff" - obviously much nicer, and better for both usability and search engine optimization. Well unfortunately on Redhat Enterprise Linux 5 (RHEL) and CentOS 5 (which is basically the same as RHEL) the standard web server, Apache, is set to ignore these files. So here's how to fix it.
Whether you're configuring the virtual host in a separate file or in the main httpd.conf, the change you'll want to make is the same:
Step 1: enabling .htaccess files:
- In the main httpd.conf file (should be at /etc/httpd/conf/httpd.conf) search for the string "AccessFileName",
- If the line is commented out (it starts with "#") uncomment the line by removing the "#" symbol,
- Update the line to say:
- Restart Apache, reload the site and.. enjoy the error message :-)
- On to the second part..
Step 2: allowing .htaccess files to override settings:
- Find the VirtualHost configuration for the Drupal site,
- There should be a <Directory> section within that block,
- If there isn't a line that starts with AllowOverride, add a new one within the <Directory> block,
- Set the AllowOverride line to the following:
AllowOverride Options Indexes Limit FileInfo
- Restart Apache again.
- Et voila.
This will allow the Drupal .htaccess file to run and make your URLs all nice & shiny!
I've decided I'm going to merge in content from another site I run just because I no longer want to separate it from my other interests, so within the next week or two you'll see some old content fill in and probably a new category or three show up.
For a Drupal site I was developing I originally tried out the Acquia distribution but ultimately dropped it in favor of the vanilla core release. In doing so I also removed the custom Acquia modules that provided integration with their network as I wasn't going to be using it either. All was good, except that the admin menus retained an unneeded menu item named "acquia_subscription_status" that just linked to acquia.com - I had to vanquish it!
Having removed all of the custom Acquia modules I was confused as to why there was this random menu item hanging around. It wasn't part of any of the contrib modules I was using, so I grep'ed my entire site to see if something remained - it was clean. Given the admin_menu module works off the normal menus I then tried the configured menus, again to no avail. So that just left the database.
In the database it seemed fairly obvious that it should be in the menu tables, and sure enough it was. The menu_links table included a menu item that went something like this:
Sure enough, this was it. So then I just removed the menu item and..
It was still there. :-|
A quick look identified the simple fact that the menu was cached! Duh.
So, a quick "TRUNCATE cache_menu;" (or Flush All Caches -> Menu) later and life was good, the menu item was gone.
As I've been delving into Drupal theming I've discovered lots of gotchas.
The first one for today - when creating a sub-theme, if you want to override a template for a specific purpose you need to copy the parent theme's original file into your subtheme. A common example is wanting to have a custom page template for the hompage, which entails copying page.tpl.php to page-front.tpl.php. Because of a bug, aka poorly thought out "feature", your sub-theme must have a copy of both page-front.tpl.php and page.tpl.php.
This particular issue really comes into play when building a sub-sub-theme, but that's for a different post.