I've been tring to figure out why Im getting this error with the subdomain module?

Drupal's inbound URL rewriting - show/hide details Not working yet
HTTP request to http://subdomain-test.dev.apptricity.com/subdomain/test resulted in an internal Drupal path of . It should have been ~subdomain-test/subdomain/test

The custom_url_rewrite_inbound() function in settings.php is rewriting the internal path incorrectly. Did you patch settings.php? See readme.txt for instructions.

I copied and pasted the code in the settings file and also uncommented out the cookie line and I have celan URLS enabled.

Is there anyone who has had this same problem?

Comments

mrgoltra’s picture

I am getting this warning. Even on a fresh install. Followed instructions over and over just couldn't get to work.

setvik’s picture

@trinin: I haven't seen this specific warning message before, where it rewrites the URL to nothing. What version of Drupal are you using? Are you using the 1.5 version of subdomain? What other modules are installed? Are you able to get subdomain running on a fresh install of Drupal with pathauto and token?

@mrgoltra: do you have additional modules installed? Is your message *exactly* the same as the message above? is this the only error message on that screen?

mrgoltra’s picture

same error. no additional modules except what is needed.

setvik’s picture

The only thing i can think of is if conflicting modules are installed (e.g. domain or global redirect).

Another possible cause could be rogue URL rewrite rules in your .htaccess file or Apache configuration.

Other than that i'm not sure.

himagarwal’s picture

had the same problem, got it working after subdomain wildcard was setup by the hostgator

sadist’s picture

I am having this particular problem. Same error message. Using the latest version of Drupal, tried both the release and dev version of subdomain.module.

I never had this problem with my previous VPS which I ran few Drupal sites. But I have to move to a new one, and the only difference is, it doesn't use CPanel.

I'd checked everything, all Apache .conf files, DNS settings, etc. At the Subdomain's settings page, all things reported Passed except for the 'Web Server' and 'Inbound URL Rewriting'.

And I'm just using the default .htaccess file.

So now, I don't know what else to check. Any help please? :(

abor’s picture

Got the same problem as @sadist. Using Organic Groups, Domain Access, Taxonomy Menu and Global Redirect at the same time also got cPanel though.

I've got the following error message at subdomain settings:

Web server - show/hide details	Not working yet

HTTP request to http://subdomain-test. **************.com/subdomain/test returned the following result:
HTTP_HOST:	
QUERY_STRING:	
REQUEST_URI:	
SCRIPT_FILENAME:	
drupal_get_normal_path:	

Your web server is not routing subdomains to your Drupal directory.
Possible Solutions:

    * If you're running Apache, confirm you have the wildcard directive, ServerAlias *. **************.com, in the VirtualHost declaration in your Apache configuration
    * Confirm there are no rogue URL rewrite rules in your Apache configuration or .htaccess file

Drupal's inbound URL rewriting - show/hide details	Not working yet
HTTP request to http://subdomain-test. **************.com/subdomain/test resulted in an internal Drupal path of . It should have been ~subdomain-test/subdomain/test

The custom_url_rewrite_inbound() function in settings.php is rewriting the internal path incorrectly. Did you patch settings.php? See readme.txt for instructions.

To be honest, the README.txt says NOT TO PATCH settings.php states as it is no longer required:

Subdomain no longer needs the custom functions in settings.php
Please review your settings.php and remove the following two
functions if present ... 

These settings aren't present so I didn't have to remove them, right????
Then why do I have to patch it? Also how?

And I just got the following message from my webmaster:

Hello,

We have created the wild card subdomain *. **************.com  in cpanel. 

Apache configuration of *. **************.com is shown below.

=========
<VirtualHost ***.**.***.***:80>
    ServerName **************.com
    ServerAlias *. **************.com
    DocumentRoot /home/ **************/public_html
    ServerAdmin webmaster@ **************.com
=========

*. **************.com is also working fine now.

===============
*. **************.com. 14400 IN      A       ***.**.***.***
 **************.com. 1000    IN      NS      ns2. **************.com.
 **************.com. 1000    IN      NS      ns1. **************.com.
;; Received 142 bytes from **.***.***.**#53(ns1. **************.com) in 308 ms
===============

We tested a few URLs like http://123456789. **************.com/test.htm, http://anythinghere. **************.com/test.htm etc and they worked fine.

A snapshot of cpanel is also attached for your reference.

Kindly let us know if you need any more help in this matter and we shall be glad to help you out.

So the settings are just like as it has to be written in the install...

clearbrook’s picture

Exactly the same as abor I have cpanel. I set up wildcard myself through cpanel (which his admin seems to have done as well for abor) I note the ServerAlias *. **************.com line in the VirtualHost section and expect the same. (which is how it should be if done correctly if my understanding is correct)

For grins, I put in the following URL into my Browser:

http://subdomain-test.****************.org/subdomain/test

and got the following back:

SUBDOMAIN TEST
subdomain-test.****************.org
subdomain/test
subdomain/test
/home1/######/public_html/TEST5/index.php
~subdomain-test/subdomain/test

****************.org is of course my domain. It is considered an "add-on" domain and is not my primary domain.

###### is my primary domain. I am going to try and set that domain to point at this temporarily and change the cookie path as well. I'll let you know if that works...

clearbrook’s picture

Hmmm. I am suspecting this to be an internal problem with cpanel.

In cpanel, add-on domains are automatically assigned a subdomain off of the primary domain as a subdomain. You cannot delete those subdomains.

I put in the wildcard (*.######.com) for my primary domain and directed it to the directory. I could NOT redirect the primary domain itself. It seems to be hard linked at my level to my the root of my www subdirectory, and for security reasons, I can see why that should be so.

http://######.com/ still directed to my primary site

http://www.######.com/ still directed to my primary site

http://garbage.######.com/user directed to my drupal site and login

I hadn't changed my cookie domain and not even logging in, it took me to my drupal domain. (looked at the valid cookie and decided I was logged in -- LOL!!!)

I am going to try something else...

clearbrook’s picture

Lunch break is over. Have to get back to this later...

I am hoping that the "/home1/######/public_html/TEST5/index.php" line I got in the above testing sheds some light on what is going on. I am pretty sure that is NOT what the subdomain module is expecting to see.

;'{P~~~

rastarr’s picture

Has anyone got this to work properly under CPanel controlled domains?
This is starting to drive me a little crazy :)

brylie’s picture

Title: is there a fix for this?Drupal's inbound URL rewriting » Page not found.
Version: 6.x-1.x-dev » 6.x-1.7
Category: support » bug

We are getting 'Page not found' errors on every sub-domain after upgrading to Drupal 6.17. All Subdomain Prerequisites are green prior to the update. After the update we get the same errors as abor in comment #7 ("Webserver" & "Drupal's inbound URL rewriting")

rastarr’s picture

Hi,

I'd suggest you set your cookie parameter to .example.com (note the preceding ".") - this was a subtle change in 6.17 and one that had me stumped for some time until I stumbled upon it.

dejan.maric.max’s picture

Many thanks, adding a preceding `.` e.g. $cookie_domain ='.example.com'; in $cookie_domain solved the inbound problem!

cblin’s picture

+1 for an update of the error message saying that settings.php must be patched for the inbound and outbound URL rewrite

+1 for an update to the documentation to say that from 6.17, the cookie_domain must me preceeded by a dot

+1 to add a check on the "Clean URLs" enabled (this one take may so long to figure because my new default apache2 config does not have the mod_rewrite enabled)

Hope this ticket will get some attention of the maintainer

zarrarnyc’s picture

I am using Plesk and Drupal 6.16, and after much configuration, got all the pre-reqs working according to the included readme.txt. Everything is a green light. The only issue now is that the subdomains are returning a 'page not found' error. Also, I have used suggestions from comment #13, #14 regarding the addition of a . (dot) in D 6.16 and still am getting a 'page not found' . I hope this issue can be resolved.

zarrarnyc’s picture

POSSIBLE SOLUTION FOUND
After much searching... the possible culprit in my scenario was that PHP needed to be updated to 5.2. This solved the problem partially. The actual creation of subdomains was noticed when I accidentally left a taxonomy term in all lowercase... and it was this term that had a subdomain. After changing the case for the taxonomy terms... the Subdomain module instantly created subdomains. I hope this helps.

wizonesolutions’s picture

There's another simple solution to this one that I found which is simply to go to the Subdomain settings page and press the Save button. It doesn't record the "www" exclusion by default, even though it's shown there. I jumped through hoops for hours before finally duplicating the live config on my local site and taking it through the debugger. I saw that it returned zilch for the exclusions. Voilà! Hit save button and all good.

Robin Millette’s picture

$cookie_domain detection was a bit weird in the debug code:

function subdomain_check_cookie_domain() {
$settings = file_get_contents(conf_path() . '/settings.php');
$settings = str_replace(chr(13).chr(10), "\n", $settings);
$settings = explode("\n",$settings);

foreach ($settings as $setting) {
if (strpos($setting, '$cookie_domain') !== FALSE) {
eval($setting);
break;
}
}

I've removed all that and replaced it with this:

global $cookie_domain;

Maybe I'm missing something. I had to fix it since, instead of uncommenting the $cookie_domain variable in my settings.php file, I added another line below it. But the code above found the first appearance of 'cookie_domain', the one that was commented, and was using that instead of the proper value for cookie_domain.

I hope that makes sense to someone...

zazinteractive’s picture

The preceding "." just solved the problem for me on Drupal 6.20 using 6.x-1.7. Thanks rastarr