PDA

View Full Version : Sub-domain Problems



Caoimhin
08-18-2009, 03:39 PM
I have a sub-domain (actually a sub-sub-sub-domain) that looks something like sub.sub.sub.domain.com. The root level works fine (sub.sub.sub.domain.com/index.php) but anything lower (sub.sub.sub.domain.com/directory/index.php) fails with a lot of 500 error codes.

Any ideas? :confused:

Early Out
08-18-2009, 04:15 PM
Maybe there's an internal limit on the depth of subdomain levels you can have.

But really, why would anyone be creating sub-sub-sub domains? What use would that ever be?

At any rate, you should probably contact BH support, since none of us can examine your directory structure and .htaccess files to see what's happening. A 500 error can mean almost anything.

JND
08-18-2009, 04:20 PM
But really, why would anyone be creating sub-sub-sub domains? What use would that ever be?
They are used to spell out "catchy phrases" in lieu of obtaining the actual (lengthy) domain name.

Early Out
08-18-2009, 04:32 PM
They are used to spell out "catchy phrases" in lieu of obtaining the actual (lengthy) domain name.
Yeah, I suppose. That just strikes me as being hopelessly "gimmicky." Better to bring people to your site with good content, and give them a truly useful menu system to find what they want.

Caoimhin
08-19-2009, 11:32 AM
Maybe there's an internal limit on the depth of subdomain levels you can have.

But really, why would anyone be creating sub-sub-sub domains? What use would that ever be?

At any rate, you should probably contact BH support, since none of us can examine your directory structure and .htaccess files to see what's happening. A 500 error can mean almost anything.

I have contacted support. So far they haven't said there's a limit to the depth...but then again, they're trying to tell me there isn't a problem. :eek:


Yeah, I suppose. That just strikes me as being hopelessly "gimmicky." Better to bring people to your site with good content, and give them a truly useful menu system to find what they want.

Thanks for your judgment. :rolleyes: Not that I need to waste my time explaining myself, but my domain structure is setup the way it is to test multiple versions of various web applications that I develop. So, I'll have test1.app1.mydevelopmentsite.mydomain.com, test2.app1..., test1.app2..., etc. It is a structure that, until now, has worked well for me and keeps everything organized. No public content.

Early Out
08-19-2009, 12:03 PM
Then I'm even more mystified. You don't need to create subdomains to do that. Just point to mydomain.com/mydevelopmentsite/app1/test1 or mydomain.com/mydevelopmentsite/app1/test2, etc.

Let us know what support says, in any case.

Caoimhin
08-19-2009, 12:11 PM
Then I'm even more mystified. You don't need to create subdomains to do that. Just point to mydomain.com/mydevelopmentsite/app1/test1 or mydomain.com/mydevelopmentsite/app1/test2, etc.

Let us know what support says, in any case.

Several of the apps generate links based on document root. Placing the app in a sub-directory would break the links.

I'll keep you posted. So far, no help. Here's the error I'm getting -- 500 Server Error: A misconfiguration on the server caused a hiccup. Check the server logs, fix the problem, then try again.

Now, for my other subdomains I've never had to change the .htaccess file or do anything with rewrite rules, but I'm thinking this could be a possible cause. Any thoughts on that?

Early Out
08-19-2009, 12:15 PM
That occurred to me after I posted - the doc root really is the only internal thing that changes if you create a subdomain instead of just using subdirectories.

Caoimhin
08-19-2009, 12:47 PM
So, through some trial and error I think I've found the source of my problem (which I think support could have found easily just by looking at the apache server logs). In my .htaccess file I'm using 'php_value include_path'. When I comment this out, things seem to work okay, except for not finding the files I need from my include_path. Any ideas for a work-around?

Caoimhin
08-19-2009, 02:11 PM
So, no response from support since Wed, 19 Aug 2009 04:51:27 -0600 (according to my support ticket), but here's what I've discovered.

It looks like in order to set the include_path in the .htaccess file the Apache config file needs to have AllowOverride enabled:


AllowOverride Options
AllowOverride All

I asked support if this is enabled or can be enabled. Like I said, no response so far.

In searching for a work-around, I found that if I duplicate my php.ini file into each directory (within which I define my include_path), it works fine. I thought that php would use the ini file in my ~/public_html directory, but it appears that I need an ini file in each and every subdirectory. I've tried both regular PHP5 and PHP5 FastCGI and both exhibit the same behavior.

Early Out
08-19-2009, 02:47 PM
You shouldn't be putting in tickets. These are sometimes answered quickly, but sometimes take a few days. Use Live Chat.

Re: php.ini. Have you tried the "PHP5 (Single php.ini)" option? Easier than manually copying php.ini to every subdirectory.

Caoimhin
08-19-2009, 02:56 PM
You shouldn't be putting in tickets. These are sometimes answered quickly, but sometimes take a few days. Use Live Chat.

Re: php.ini. Have you tried the "PHP5 (Single php.ini)" option? Easier than manually copying php.ini to every subdirectory.
Yeah. I tried the Single php.ini option and it didn't seem to work as advertised. It reverts back to /usr/local/lib/php.ini and doesn't use the one in ~/public_html. It may be that it only works per domain/subdomain..??? Dunno. But it seems to work the same whether i use "PHP5 (Single php.ini)" or "PHP5 (FastCGI)".

Caoimhin
08-19-2009, 03:47 PM
Just got off of live chat. They weren't able to help...told me to open a ticket. They did say that the AllowOverride directive couldn't be changed for me so I'm stuck using the php.ini file. The only remaining question is how do I enable the single file php5? I have noticed that even though I've selected that option on the PHP config page, when I run phpinfo() it still indicates I'm running FastCGI. I'm not sure how long it takes to update, but it's been that way for awhile now.