UPDATE: Solved. The hosting environment was OK and the test result was wrong. See bug report at http://drupal.org/node/1178850.

Hello all

I'm really close to having my first ever Drupal site ready to go live. Excitement!

But I am having a puzzle over Clean URLs, possibly connected with using an addon domain.

I developed my site offline and Clean URLs were working on my local machine. This is Drupal 7 on Apache on Linux.

My online hosting is at Compila and the Drupal site is going to be on an addon domain, call it www.addon-domain-example.co.uk. (I.e. the real address is gonna be like www.main-domain-example.co.uk/hiddendirectory and then the addon domain points to that.)

Before trying to upload my real site, I did a clean Drupal 7 install in a different subdirectory - www.main-domain-example.co.uk/trialdirectory - just to see if everything was basically working together OK. On that trial install, Clean URLs work - they still work now.

However, on my real site, they don't. It doesn't seem to matter whether I access it via www.addon-domain-example.co.uk or via www.main-domain-example.co.uk/hiddendirectory/ . It doesn't seem to matter either whether the addon domain forwarding (or whatever you call it) is active or not - I can delete the addon domain via cpanel and it doesn't help.

If I go to the enable clean URLs (overlay) page, I just get the explanation and the button "Run the Clean URLs test". And if I click the button, it "thinks for a bit" and then gives me the same again. I seem to recall this is what the dev site did when Apache on my machine didn't yet have the right modules, so I think it basically means "Test failed".

Because the trial install worked OK, I don't see how it can be something lacking at the hosting.

I started off with the default .htaccess that Drupal 7 installed. So that worked OK on my machine and on the trial site.

I'm aware that the real site has hard-coded "www.addon-domain-example.co.uk"s here and there, so it is significantly different in that way from the trial. And that's where my suspicions have gone. But it could be something else.

I subsequently found http://drupal.org/node/1028568#comment-3997076 and I tried making a .htaccess file with the line replacement suggested there,
RewriteRule ^(.*)$ /index.php?q=$1 [L,QSA]
but that didn't seem to make any difference.
(I don't know what that actually means or why it would maybe help, I was just trying it.)

Any ideas?

Thanks in advance

Jennifer

Comments

Oddly enough, Clean URLs do seem to be partly working.

That is, if I manually type in the equivalent of http://www.addon-domain-example.co.uk/page-name then it correctly serves that page.

On the other hand if I click on a menu item, it calls the "dirty" URL and correctly serves that.

Using PHPMyAdmin I went to look in the "variables" table, thinking I would see whether Drupal "thought" they were on or off. I was able to find the clean_url variable. But it only told me the answer was a binary blob, value [BLOB - 4B], and I don't know how to read that.

A likely explanation has just occurred to me of this at-first-seemingly-strange phenomenon.

I think it's like this:

(a) Drupal's "Use Clean URLs" setting is how Drupal decides/knows whether to generate "clean" or "dirty" URLs. Hence the menus generating "dirty" URLs.

(b) Drupal (obviously) can't stop me typing in the clean ones.

(c) mod_rewrite is following the instructions in .htaccess where it can, and in at least some cases, it can - hence the typed-in clean addresses that work. In other words, mod_rewrite has no way of knowing that Drupal has an on/off setting which is set to off - it just goes on doing its thing.

(d) The Clean URLs test fails even though some redirections work. This would be either because there are genuine cases of not-working redirections which the test knows about, or because the test is flawed.

Hence at-first-seemingly-strange mix of working and not working.

Maybe this isn't it of course :-) but it's one hypothesis...

But typing in the clean ones doesn't seem to be working any more. I'm not sure when or why that changed (it may have only been true when I first did the upload). Instead I now get "500 Internal Server Error".

Hmm, but http://www.addon-domain-example.co.uk/user does still redirect successfully to http://www.addon-domain-example.co.uk/index.php?q=user. So it's only some of the clean ones that (I think) were working before and now aren't.

Let's see if I get this straight.

You're example.com You made a newsite. You can get to it by going to example.com Is that right?

And you tested this by putting it in /trialdirectory - where it works. How do you get to it here? example.com/newsite? example.com/trialdirectory?

Then decided to change it to /hiddendirectory - where Clean URLs do not work.
This probably is because your hosts setup will allow somebody to type in example.com and they will see whatever is in /hiddendirectory - which makes it the root for the website.

I'm a little unclear what exactly moved from /trialdirectory to /hiddendirectory
Is it the entire drupal install? Where is newsite installed in drupal? Do you have it under sites? Or as the default drupal site?

No, it's different from this. Let me give the explanation another try.

Nothing moved from /trialdirectory to /hiddendirectory.

www.main-domain-example.co.uk/trialdirectory had (and has) a fresh D7, installed & set up where it is now and not moved from anywhere else. It's got no artwork, no theming by me and only one page. I did this prior to uploading the "real" site, to see if my hosting was working and specifically to discover whether Clean URLs would work there - which on the trial, they do.

www.main-domain-example.co.uk/hiddendirectory is a (slightly amended) copy of my offline development site. As originally built, on localhost on my own machine, Clean URLs were working. In the online copy, they're not (yet).

In other words, I made two sites. One is the one I really want to exist, which I made first (inc theming & initial content) on my own PC and subsequently uploaded to /hiddendirectory. The other is almost just a dummy - except that it does demonstrate that my hosting can in principle handle Clean URLs.

What I probably wasn't clear about (sorry about that) is that /hiddendirectory isn't actually hidden in the sense of being invisible. It's hidden in the sense that it's got no links to it from anywhere else in the web. I can go there any time I like by typing the subdirectory address into the address bar, but that subdirectory address isn't its address as far as the world knows. It is also accessible via another unrelated domain name which is the one that the Drupal installation knows (or ought to) and the one by which the world will know it. All of that follows from the nature of add-on domains.

(The world can in fact see it now via its intended domain name, but only the "Site maintenance" page as I don't want Google et al to start crawling my unclean URLs.)

To answer your question about Drupal directories: In my real site, the interesting theme stuff is in /sites/all/themes/mytheme. In the trial site it's had virtually nothing done to it, so its behaviour is whatever the default is.

Are you thinking that the two installs might be interfering with each other? I've not seen any evidence of that, and I don't really see why they should be. But I could take down the trial one if I wanted to make sure. I don't really want to yet as I've been finding it useful to have an un-messed-with one to compare the real one with.

Hope that makes the whole scenario a bit clearer! Thanks for asking.

I wonder what have you set as $base_url in settings.php?

Hmm, good question.

::goes to look::

It's my addon domain.
(settings.php line in the form $base_url = 'http://www.addon-domain-example.co.uk';)

When I investigated just now, I realised it had previously been
$base_url = 'http://addon-domain-example.co.uk'; (no www)
which was a mistake by me inasmuch as I've always included www in the canonical address. (This is a replacement site for a domain which already has incoming links.) But correcting that hasn't affected the Clean URL behaviour. I'm not totally surprised, because if the $base_url was wrong I'd have thought more things would be falling over.

What do you think - does that sound right?

Incidentally I've asked Compila (hosting company) if I can get sight of the Apache RewriteLog for my site(s), but they haven't answered yet.

It should be set to the absolute URL to your Drupal installation. This is not always the URL for your site. In your case it might very well be www.main-domain-example.co.uk/trialdirectory

That's what it is on the one that works?

In your case it might very well be www.main-domain-example.co.uk/trialdirectory

Thanks for the suggestion. Tried that just now, and I had odd results inasmuch as I tried it twice (as I thought, identically) and got different results each time - but neither was right.

The first time, what was happening was Drupal was serving the pages by their main-domain names,

e.g. where it was previously serving
http://www.addon-domain-example.co.uk/?q=faq

it was now
http://www.main-domain-example.co.uk/trialdirectory/?q=faq

Which isn't exactly incorrect, from Drupal's point of view, but if I wanted it to use those addresses, then I'd have no need to be messing with an add-on domain!

Then I put it back to the addon domain; then I tried your suggestion again because I'd forgotten to look at the Clean URLs page while I was there, and this time it started doing

http://www.addon-domain-example.co.uk/trialdirectory/?q=faq

which makes no sense at all, and indeed was giving file not found errors. So I've put it back again to base url being the addon domain, which does at least serve the pages and give them basically correct addresses, even though the URLs aren't clean.

I'm becoming more & more convinced that what I need to fix (if indeed it's fixable) is something subtle with .htaccess. Unfortunately I still haven't managed to extract the Apache RewriteLog from Compila. Really wishing the Drupal Clean URLs test would give some more verbose results when it fails, as well :-/

Thanks again for your help - I do appreciate someone taking an interest, and at least I'm learning something, even if we've not actually solved it :-)

I have a friend who was having some problems. He changed his .htaccess from this -

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

to this -

RewriteRule ^(.*)$ http://www.example.com/index.php?q=$1 [L,QSA]

This helped him. Don't know that it would help you.

Thanks, don't think I'd seen that one yet. Yes, I think my next step has to be to systematically try out all the various suggestions of things to change in .htaccess and see if any of them fixes it. Wish I had a better understanding of how that all works, but brute force "throwing time at the problem" may prove to be the only way :-)

Are you certain the server is reading in the .htaccess file?

You can test it by typing 'test' in there someplace.

This should cause a server error when you go to your site.

Yes it was - thanks for your patience on this thread but the answer was actually a D7 bug! see edit above. The hosting environment was OK all along!!

If there is a php.ini(or php5.ini) file in root(main site's root), then copy it to the sub folder. That will make php environment same as main domain's.

// Ayesh

If there is a php.ini(or php5.ini) file in root(main site's root)

There isn't... but thanks for the suggestion.

(Differing php environments doesn't seem to me a likely solution, because of the trial D7 working fine in an equivalent subdirectory - unless I'm missing something, which is quite possible :-) )