I have been working on a firewalled (remember this for later) development server over the last couple of weeks at the AMA. With entries into host files, .htaccess files and firewall rules to prohibit those not developing the updated site from accessing it we considered it pretty locked down.
Development was going well with custom and contrib modules almost finished and the theme pulling together well. Drupal requires a few extra configuration options be set such as user permissions, metatags, labels on fields and things like sitename/slogan. One of the final things on the checklist was to turn clean URLs on. After navigating to the clean URLs page I ran the check and it failed;
ok this has happened a few times before, let's just revisit the handbook and go over the steps.
- Ensure mod_rewrite is on.
- The server is debian so a quick apachectl -M showed rewrite_module (shared) so that was fine.
- Ensure the httpd.conf file allows the Drupal .htaccess file to overwrite it?
<Directory /home/amalone/web/ama/> AllowOverride All Order allow,deny allow from all </Directory>
- Looks good to me.
- Check the .htaccess is even being read by putting some junk text in there and see if it breaks the site.
- Error 500. Check that off the list.
At this point I decided to give up for a while and assume some weird magic would allow me to enable clean URLs at some point in future since I was at a loss.
Eventually I got back round to it and did some more investigation. Looking at the code in the system module (system.admin.inc) I could see that when the user wanted to check if their site was ready for clean URLs drupal does a drupal_http_request to itself at an address of http://example.com/admin/config/search/clean-urls/check which would return http code 200 (OK) if clean URLs can be enabled and would fail if it could not be enabled.
Thinking on my feet I immediately requested that URL in my browser and received the following json output:
So where is the issue?
Remember at the very top of this post when I said it was a firewalled server due to it being under development? Turns out the server could not access itself from outside, so a relative link as a menu callback would have worked but the absolute link which involved Drupal calling itself from external to the server was blocked by the firewall.
Obviously I could have altered the core code or opened up the firewall so clean URLs worked but that's not advisable for a number of reasons.
I decided the best thing to get clean URLs working without altering anything on the server was to change the variable in the database with the following:
update variable set value = 'i:1;' where name = 'clean_url';
URLs were clean, the site wasn't broken, one step closer to site release.