Interworx Subdomains vs Plesk Subdomains

I’ve been using Plesk for a long time and have found it to be a solid control panel overall. It blows the doors off of cPanel for sure (why anyone uses cPanel is simply beyond my comprehension).

Anyway, I’ve just recently started using Interworx on our newest server. I’m still figuring out the similarities and differences from Plesk. One thing I’m not clear on is subdomains.

In Plesk, if you create dev.domain.com as a subdomain, it’s created in its own folder which now has its own document_root for scripts and such. We setup subdomains like this all the time in order to run the development version of the site. It’s been very useful since none of the settings need to be changed in the files.

However, it appears when I create a subdomain in Interworx, it adds a directory in the main root directory (in this case, dev). When I browse to http://dev.domain.com/ I’m redirected to http://www.domain.com/dev/. This seems all wrong to me. I’d think we’d at least have the option of having a subdomain as a simple redirect or a stand-alone directory operating as its own root. I just don’t see the point of having any subdomain if it’s no different than just typing www.domain.com/subdomain ?? What is the big advantage here?

I’m sure our scripts will have to be altered to run in this sub directory since it won’t see itself as being in the document_root. Do you understand my dilemma here? I can no longer keep the script using things like: require_once $_SERVER[‘DOCUMENT_ROOT’] . ‘/inc/config.php’;

I used to love subdomains, but really I’m more a fan of sub directories. You can set up SiteWorx accounts for sub.domain.com if you like, and get everything seperated.

IMO, including based on DOCUMENT_ROOT is asking for trouble down the road, just that’s just me.

what do you suggest instead of $_SERVER[‘DOCUMENT_ROOT’] ? Surely, you wouldn’t want to hard code the path in any script. Your code wouldn’t be portable otherwise.

whoisjb,

Just to clarify, we use rewrites for subdomains, not redirects. Redirects will actually send the user to a new URL, and the change will appear in the URL bar. A rewrite is more or less transparent, so while technically you are viewing the contents of domain.com/sub, the URL in the browser will still show sub.domain.com.

Personally, I rarely refer to $_SERVER[‘DOCUMENT_ROOT’] directly in my scripts. What if my app moves to some place deeper in document root? Then I have to modify all the locations I specifically used $_SERVER[‘DOCUMENT_ROOT’]. If you look at a lot of the more popular PHP apps out there, they all have some form of a config.php file, where they define their own variables for use throughout the app. This allows you to define app-wide constants, and allows you to make app-wide changes in one location. This allows for maximum portability.

However, if that’s not acceptable to you, then CMI’s suggestion will give you the functionality you’re looking for in the current version of InterWorx: create a SiteWorx account for sub.domain.com.

In v.3.0, you’ll have another option available to you: secondary domains. :slight_smile: You can continue to create sub.domain.com as a subdomain (using rewrites), create a new sub.domain.com SiteWorx account (creating a new user and document root), or create a Secondary domain which will also create a new document root, but the document root will be a subfolder of the main SiteWorx account.

I use either specified paths (typically set in a config.php file as Socheat mentioned, which you don’t even need to set because you can always dirname(FILE)) and relitive paths (…/…/some.inc.php).

Both options are very handy and make moving apps around very easy.