Apache's VirtualDocumentRoot configuration requires a change in drupal's htaccess file, or Clean URLs will break. This tiny adjustment (the leading / on index.php) is very difficult for anyone to know about, and VERY difficult to discover or fix when your drupal installation isn't working. By adding these few lines to htaccess explaining what lines to use for what configuration, some (admittedly not all) of those user's will find this in htaccess and solve the problem more easily.

  # Rewrite current-style URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]

becomes

  # Rewrite current-style URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d

  # For standard virtualhosts
  RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]
  # For virtualdocumentroot
  #RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]

See these nodes for more details about the issue: http://drupal.org/node/86667 http://drupal.org/node/8147

Note, on brief testing, using the slash in typical VirtualHost configurations seems not to break Clean URLs, although further testing would be required.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Excuse my poor eyes. I don't see the difference between this

  # For standard virtualhosts
  RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]

and this

  # For virtualdocumentroot
  #RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]

except for the comment character.

Bevan’s picture

My Bad. Sorry.

This is the line in current distributions:

  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

This is what works for VirtualDocumentRoot configurations

  RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]

This is the patch I propose for .htaccess to make life easier for those trying to find / solve this bug. (I've also tidied up the comments.)

  # Rewrite current-style URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d

  # For standard VirtualHost configurations
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
  # For VirtualDocumentRoot configurations
  #RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]
drumm’s picture

Version: 5.x-dev » 6.x-dev
Status: Needs review » Needs work

This is not a patchfile, see http://drupal.org/diffandpatch.

Bevan’s picture

Sorry that I don't know everything thing yet.

Please read 'change' when I say 'patch'.

I'll try and know everything.

Bevan’s picture

FileSize
350 bytes

God damn! I've just spent 4 hours debugging my server, to find this #¬¢∞·&$% leading slash was the error. +1 (A really big one) to get this into drupal six.

Now that I've learnt how to do patches... Attached.

slantview’s picture

I've also fixed this by changing these lines:

  # Modify the RewriteBase if you are using Drupal in a subdirectory and
  # the rewrite rules are not working properly.
  #RewriteBase /drupal

To

  # Modify the RewriteBase if you are using Drupal in a subdirectory and
  # the rewrite rules are not working properly.
  RewriteBase /
Bevan’s picture

I've recently learned my patch breaks installations running in sub directories.

B/

Anonymous’s picture

@bevan: Have you tried slantview's suggestion at #6? Does it work for you?

Bevan’s picture

Status: Needs work » Needs review

#6 works for me and is a better solution than the one I suggested. So I suggest this patch instead:

Index: .htaccess
===================================================================
RCS file: /cvs/drupal/drupal/.htaccess,v
retrieving revision 1.87
diff -r1.87 .htaccess
85,87c85,89
<   # Modify the RewriteBase if you are using Drupal in a subdirectory and
<   # the rewrite rules are not working properly.
<   #RewriteBase /drupal
---
>   # Modify the RewriteBase if you are using Drupal in a subdirectory and the
>   # rewrite rules are not working properly.  Add the name of the subdirectory
>   # after the slash.  e.g. if your drupal site runs out of example.com/drupal,
>   # change "RewriteBase /" to "RewriteBase /drupal" on the next line.
>   RewriteBase /

This will require that sites running in subdirectories modify .htaccess for the site to work. However I think this is the case already for sites running in subdirectories. It's definitely the case for sites running in subdirectories of a VirtualDocumentRoot, can someone with regular VirtualHost please confirm?

If I'm wrong, and sites running in subdirectories of a VirtualHost don't normally need modifications to .htaccess, then this patch will probably now require modifications to those sites' .htaccess. In that case I'll rework this patch.

dman’s picture

I think you are thrashing a bit, and creating problems for yourself. Putting an absolute path or leading slash into the config file makes it much less general-purpose.

In my experience, RewriteBase is totally optional, indeed to be avoided unless all else fails. It's an over-ride that should not be neccessary unless the paths are confused.

I have a dozen Drupal instances running in subdirs, or multisites, or multisites in subdirs, also addressed via virtual hostnames etc - on one apache virtualhost development machine.
RewriteBase is not required, and must not be. Adding a RewriteBase for one site breaks it for the rest.

I've not worked with VirtualDocumentRoot , but I hope there is a more graceful fix to your problem.

slantview’s picture

Status: Needs review » Needs work

I'm sorry, I would have to agree with dman on this. The specific fix I gave is for VirtualDocumentRoot only. I would not suggest uncommenting that in the main file as it is the exception, not the rule. If you want to contribute a patch back, you should add a comment to the file that uncommenting that particular line will help us users with VirtualDocumentRoot.

I have worked on lots and lots of Drupal sites, and only our development server has needed that and one time I used it for Rewriting in a sub-directory.

Glad the fix worked for you however.

Bevan’s picture

Status: Needs work » Needs review
FileSize
1.27 KB

I wondered if that was the case. Thanks for clarifying. Well this has all boiled down to a few additional comments. I also tidied up other comments in the file for consistency. I noticed that the Id CVS keyword is at the bottom in this file. Normally it's at the top right? Any known reason for this exception?

dman’s picture

Useful comments and documentation are a welcome contribution, but the patch is a bit unclean, not sure why (line endings? whitespace?)

Perhaps you could describe exactly what you had to do as a handbook page contribution!

As I said, I don't know about VirtualDocumentRoot, (it's an edge case for me) but I think your comments to the file are appropriate.
But some more detailed clarification would be good. (They would be good for the original comment also ;-)

Anonymous’s picture

Status: Needs review » Needs work

As dman pointed out the patch is unclean with spacing issues. Also, please use the unified difference switch, it is more pleasing to the eyes.

Bevan’s picture

are these the spacing issues you refer to?

58a59
> 
60a62
> 

I added some line breaks and whitespace to make the code and comments easier to read and more consistent throughout the file. I think this is important, as comments in .htaccess are probably the most often-read by newbies.

How do I do cvs diff with the 'unified difference switch'?

@dman

A handbook would be a good supplement to this, but I think it's important to include some mention of VirtualDocumentRoot in .htaccess. The aim of this issue is to make it easier for users of drupal to solve clean URL issues. Currently there is no reason for a drupal user to think that their VirtualDocumentRoot configuration might break it (This is arguably an issue with Apache/VirtualDocumentRoot, but apache developers have washed their hands of it and "won't fix" -- I can't find the link right now). Therefore attempts to fix the issue are often trial and error (as mine were the first time). This is tedious and frustrating.

Most of this trial and error work happens in .htaccess. Therefore htaccess is the best place to let the user know that VirtualDocumentRoot will break clean URLs (and offer a fix for it). When users start trying to solve an unknown problem, I think many search documentation or read inline comments -- particularly the latter in the case of issues surrounding htaccess.

dman’s picture

Yeah sure, do both. Add a line about it in the htaccess yes, but actually explain what the exact problem is and why that workaround fixes it in a documentation supplement.

Because .htaccess is an important place for many custom set-ups, it's important to note what the side-effects may be also. To avoid even more trial-and-error or follow-on breakages.

chx’s picture

Priority: Normal » Minor
Status: Needs work » Active

I am inclined to won't fix this. Where do you draw the line between making htaccess comments for every possible Apache configuration? Virtualdocumentroot is quite an advanced feature, if you are running that then you know what are you doing. If your site runs that then they should have a support article on it like http://modwest.com/help/kb1-292.html . I do not see a proper patch to be worked with so I changed the issue to be active.

Bevan’s picture

I wouldn't have considered VirtualDocumentRoot an advanced configuration. It might be uncommon, but it's quite simple to set up. I'm not a sysadmin -- I mostly do theming work with drupal and some consulting -- and I set it up in MAMP to make it quick and easy to deploy new dev sites -- no restart required; http://httpd.apache.org/docs/2.0/mod/mod_vhost_alias.html#virtualdocumen...

I have the same number of lines in my included apache .conf file as I would have for one virtualhost.

Also I suspect it's uncommon-ness is largely thanks to lack of support for it -- mostly on the part of apache, but also from projects like drupal.

Why *should* we draw a line? There is a finite number of apache configurations, and even if we catered for every single one the comments and/or documentation would still be valuable and usable. I agree it's important to make these comments as concise and clear as possible, and to make the more common issues more prominent. And move detailed documentation into the handbook.

Can someone please answer my question; How do I do cvs diff with the 'unified difference switch'?

chx’s picture

Bevan’s picture

FileSize
2.04 KB

Thanks chx! :)

Anonymous’s picture

Status: Active » Needs work

The patch is better to read but still needs work.

The removal of the space for example

-  # RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
-  # RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
+  #RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
+  #RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]

doesn't make the comments easier to read. Please adjust the patch without those changes.

Bevan’s picture

Status: Needs work » Needs review

Those lines aren't comments. They are directives that can be uncommented to have an effect on the configuration. To make them consistent with the other commented-out directives in the file, I removed the space between the first character of the directive and the pound-sign. This also marks the directives distinctly from the comments and makes them easy to distinguish.

dman’s picture

Apropos of nothing, "£" is the Pound sign. "#" is the HASH sign.

Yes, they may appear on the same place on UK/US keyboards, but there's no other good reason for confusing them.
I actually understood the "Comments that may be uncommented" better without the extra space, as per this patch, but it's certainly not worth making things difficult about..

Anonymous’s picture

Status: Needs review » Needs work

But they are comments none the less and for standard structure a space needs to follow it. I'm being difficult about it because others will be even more so.

Bevan’s picture

FileSize
1.56 KB

I think it enhances usability without the space -- but it's really not worth wasting more time over. If you thinks it's important, then here you go (attached).

slantview’s picture

Hi Dan,

Just as a follow up, in the United States / Canada the "HASH" character is often referred to as the "pound" sign. You can find references at http://en.wikipedia.org/wiki/Number_sign

In some regions of the United States and Canada, the symbol is traditionally called the pound sign, but in others, the number sign. This derives from a series of abbreviations for pound, which is a unit of mass or weight. At first "lb." was used; later, printers got a special font made up of an "lb" with a line through the ascenders so that the lowercase letter "l" would not be mistaken for the number "1". Unicode character U+2114 (℔) is called the "LB Bar Symbol," and it is a cursive development of this symbol. Finally came the reduction to a combination of two horizontal (cf. skewed "=") and two forward-slash-like (cf. "//") strokes (in this respect, names like fence or square, as well as the representation of the sign containing two exactly vertical instead of slanted strokes, as in many keyboards, including cell-phones', are misleading).

Its traditional commercial use in the U.S. was such that when it followed a number, it was to be read as "pounds", as in 5# of sugar, and when it preceded a number, it was to be read 'number', as in #2 pencil. Thus the same character in a printer's type case had two uses.

Anonymous’s picture

Component: file system » other
Category: feature » task
Status: Needs work » Reviewed & tested by the community

I think the patch is ready.
I changed the Component to other because File System wasn't correct and nothing else fits.

Note to committer: This is a documentation only patch to help clarify the need to define or change RewriteBase value.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Agreed. Modified the docs to have a colon after the "following line" texts, to be in line with other comments in the file. Committed.

dman’s picture

First, yay for a commit that may help this reasonably trivial issue get to rest.

Second, thanks for the reference that explains why # may mean "pounds" to some folk (what do you call £ ? ). So maybe there is a reason beyond keyboard layouts to confuse it. I've only ever seen [the hash sign #] out-of-context meaning "number' but we learn every day. I forgot that some folk don't do decimal yet. I'd only ever known of the currency version, and not considered the legacy/imperial version. interesting.

Anonymous’s picture

Status: Fixed » Closed (fixed)
Bevan’s picture

This went into drupal 5.7: http://drupal.org/node/215269

8thom’s picture

Thanks for this work.

I run my local dev environment in VirtualDocumentRoot mode however I often work on sites that don't, so whenever I clone a repo that doesn't, I need to set the Rewritebase. Also, if the .htaccess file is committed it becomes modified and your local repo can never be clean

Not a major but can be annoying....

Anyhow I've just found a decent solution by overriding the default .htaccess file.
Just set the AccessFileName in the Virtualhost directive, I used the following :-

AccessFileName .htaccess.local .htaccess

(I've also added .htaccess.local to the global git ignore file.)

This means if you clone a site that needs the RewriteBase set you can just copy the .htaccess file as .htaccess.local uncomment this line and you're good to go.
It also won't affect other sites as it will only override if .htaccess.local is found.

Just throwing it out there incase anyone else has similar issues.

Bevan’s picture

Thanks 8thom! That's good to know. Btw, I stopped using VirtualDocumentRoot when I switched to Acquia Dev Desktop for my (L)AMP stack on Mac OS X.

8thom’s picture

Must give Acquia Dev Desktop it a try sometime.

Just been burnt too many times developing on WAMP/MAMP.
Do you know if there's plans to release Acquia Dev Desktop on Linux?

I also quite like developing on a VM as it's portable, can keep this stable (Ubuntu LTS) and still do major OS upgrades plus it's bonus to be able to snapshot the VM for those highly experimental changes which may require changes to server config, DB and code.