By gulliver on

I want to install into a non-root directory - example: 'drupal' - but not have /drupal/ in the path urls...

Example: a directory named 'sample' and created by Drupal would be publicly accessed as domainname.com/sample/ and not domainname.com/drupal/sample/.

Is this possible?

Comments

gpk’s picture

gpk commented

Yes but the details of how depend a bit on your host/server configuration. Basically if you can get the domain to point directly to the drupal folder then it should all work. Depending on server config, occasionally you need to set $base_url in settings.php and/or RewriteBase in .htaccess.

Obviously the thing to be careful with is how you specify internal URLs on the site within your content (menus etc. will automatically be generated correctly). If you specify /my_page it refers to domainname.com/my_page which is not on the site ... if you specify my_page then it will only work from pages that are at the same level in the notional URL "folder structure". Specifying the full URL including the domain name is tedious. Making all pages have PHP input format and using url() to generate the URLs is very far from ideal. You might find the pathfilter module interesting.

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

gulliver’s picture

gulliver commented

Thanks.

Sorry for my idiocy, but can you please further explain 'Basically if you can get the domain to point directly to the drupal folder then it should all work.'

Meantime, I shall go look at pathfilter.

gpk’s picture

gpk commented

When the webserver receives a request for www.example.com it needs to try to serve it from something like /users/your-username/public_html/drupal not from public_html (or whatever your own HTML root is called). That much you said in your original post. If your host uses cPanel then "Add-on domains" provide this functionality.

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

gulliver’s picture

gulliver commented

It's with 1&1 which uses it's own cp.

I need to read much more - it's all currently way over my head.

gpk’s picture

gpk commented

Looks like you must be on at least the Business package then, that includes 2 DBs.

Have a look here http://faq.oneandone.co.uk/domains/using_and_setting_up_your_domain/3.html and if makes no sense then try their tech support!! http://order.1and1.co.uk/xml/order/WebHostingService

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

gulliver’s picture

gulliver commented

Ok... it's installed in /apps/drupal/ and with some .htaccess changes, content is publicly accessible as domainname.com/apps/drupal/fileordirectoryname and also domainname.com/fileordirectoryname.

But, all the links generated by drupal point to domainname.com/apps/drupal/fileordirectoryname - so how do I have then be domainname.com/fileordirectoryname?

gpk’s picture

gpk commented

Not sure what .htaccess skullduggery you've used but it looks like you need to define $base_url in settings.php

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

gulliver’s picture

gulliver commented

For some odd reason, I now can't write to that file - getting a permission denied error when trying to do anything to /apps/drupal/sites/default/

Most odd. Replaced it with a backup and that writes ok. Can't delete the old one though.

So... install is /apps/drupal/
/apps/drupal/sites/default/settings.php has $base_url = 'http://domainname.com/apps/drupal';
/apps/drupal/.htaccess has RewriteBase /apps/drupal/
/.htaccess is as below:
(This is the minimum it'll run with - note 500 and 404 error comments)

# Various rewrite rules.

RewriteEngine on

# Modify the RewriteBase if you are using Drupal in a subdirectory and
# the rewrite rules are not working properly.
RewriteBase /apps/drupal/
#if not enabled, get 500 error

# 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]
#if not enabled, get 404 error

Content is accessible at domainname.com/apps/drupal/etc and also domainname.com/etc - but the Drupal menus include the apps/drupal/.

No idea what to do - going back to Movable Type. No, just joking. ;-)

gpk’s picture

gpk commented

What version of Drupal?
OK you've worked round it but...
Sometimes the file permissions/ownership get changed (including by Drupal for "security" reasons), so you might have to add write permission to settings.php or to default/; if you are not the owner of settings.php then you might need to make a copy and rename the new one to settings.php &c which is a bit like what you did.

Does RewriteBase / work? If not then fine.
Try $base_url = domainname.com

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

-Anti-’s picture

-Anti- commented

> I want to install into a non-root directory - example: 'drupal' - but not have /drupal/ in the path urls

I've successfully done this using htaccess.

The first thing I do, is get rid of the www on any domain or subdomain:

## globally redirect www to http:// for all domains/subdomains
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]

This just simplifies things, making the next bit easier:

RewriteCond %{HTTP_HOST} ^DOMAIN\.COM$ [NC]
RewriteRule ^$ drupal/index.php [L]
#
RewriteCond %{HTTP_HOST} ^DOMAIN\.COM$ [NC]
RewriteCond %{DOCUMENT_ROOT}/drupal%{REQUEST_URI} -f
RewriteRule .* drupal/$0 [L]
#
RewriteCond %{HTTP_HOST} ^DOMAIN\.COM$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* drupal/index.php?q=$0 [QSA]

Then in /sites/defaults/setting.php, edit: $base_url = 'http://DOMAIN.COM';

Now your browser url will look like: htpp://domain.com/sample/

And importantly, all internal relative links will be: /sites/default/files/...
as opposed to: /drupal/sites/default/files/...
This increases the portability of your site.

Note that this will not affect any subdomains - you can use them as normal.
The browser url will appear: http://sub.domain.com/

However, if you use drupal's multisite feature, I think it would be necessary to
edit each multisite's settings.php file $base_url:
http://sub.domain.com or http://domain.com/sub

Original htaccess script is here:
http://www.drupial.com/content/drupial-installing-drupal-a-subfolder

gulliver’s picture

gulliver commented

Thanks. And it didn't work. Generated 500 errors.

Here's the current deal...

The .htaccess in the root must contain at least the content below or else it gives 500 or 404 errors (see note):

# Various rewrite rules.

RewriteEngine on

# Modify the RewriteBase if you are using Drupal in a subdirectory and
# the rewrite rules are not working properly.
RewriteBase /apps/drupal/
#if not enabled, get 500 error

# 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]
#if not enabled, get 404 error

Then I tried various combinations with the /apps/drupal/.htaccess and /apps/drupal/sites/default/settings.php. Here's what happens:

WITH DRUPAL .htaccess #RewriteBase /apps/drupal/

1 settings.php #$base_url = 'http://domainname.com';
OK, but Drupal generated urls contain apps/drupal.

2 settings.php $base_url = 'http://domainname.com/apps/drupal';
OK, but Drupal generated urls contain apps/drupal.

3 settings.php $base_url = 'http://domainname.com';
No css, but Drupal generated urls don't contain apps/drupal

WITH DRUPAL .htaccess RewriteBase /apps/drupal/

1 settings.php #$base_url = 'http://domainname.com';
OK, but Drupal generated urls contain apps/drupal.

2 settings.php $base_url = 'http://domainname.com/apps/drupal';
OK, but Drupal generated urls contain apps/drupal.

3 settings.php $base_url = 'http://domainname.com';
No css, but Drupal generated urls don't contain apps/drupal

gpk’s picture

gpk commented

OK looks like 3 is the way to go but .htaccess will need some tweaking, essentially to rewrite every URL internally to make sure that it contains apps/drupal

Maybe something like this:

  # Make sure /apps/drupal/ isn't already (invisibly) in the URL e.g. as a result of a previous Rewrite
  RewriteCond %{REQUEST_URI} !/apps/drupal/
  # Rewrite the URL behind the scenes
  RewriteRule ^(.*)$ apps/drupal/$1 [L]

[updated]
This probably needs to be in the main .htaccess rather than Drupal's ... the thing is to make sure that all requests, including for CSS assets etc., include the apps/drupal part of the path. I've cribbed this from another installation - might need some tweaking to integrate it with your server/.htaccess etc.

Also the final resulting .htaccess might be a bit cumbersome but if it works then :) and can always be streamlined later

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

gulliver’s picture

gulliver commented

>might need some tweaking to integrate it with your server/.htaccess etc.

Doesn't work as-is, so something for another day.

Thanks.

gpk’s picture

gpk commented

Yeah, depends on how all your .htaccess are set up

To make it work properly in the main .htaccess it would probably also need the line I've added at the beginning here:

  # Only apply this rule to the relevant domain
  RewriteCond %{HTTP_HOST} domainname.com
  # Make sure /apps/drupal/ isn't already (invisibly) in the URL e.g. as a result of a previous Rewrite
  RewriteCond %{REQUEST_URI} !/apps/drupal/
  # Rewrite the URL behind the scenes
  RewriteRule ^(.*)$ apps/drupal/$1 [L]

This just stops it being applied to other domains you have hosted on the account. As you say, another day maybe to fix the underlying prob!

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

gulliver’s picture

gulliver commented

>This just stops it being applied to other domains you have hosted on the account.

Shouldn't make any difference - all the virtual stuff is done at main server level.

-Anti-’s picture

-Anti- commented

> Thanks. And it didn't work. Generated 500 errors.

Um, the drupal htaccess file you're talking about stays with the drupal install, in the '/drupal' folder.
You don't need to edit the drupal htaccess at all.

The stuff I wrote goes into the htaccess file in your ROOT (usually public_html).
You should have one in root, even if all it says is:

Options All -Indexes

gulliver’s picture

gulliver commented

Thanks. I was editing the root .htaccess, not the drupal one.

Also forgot to add this batch of tests:

WITH DRUPAL .htaccess RewriteBase /

1 settings.php #$base_url = 'http://domainname.com';
Loads root index page.

2 settings.php $base_url = 'http://domainname.com/apps/drupal';
Page http://domainname.com/apps/drupal loads ok, all others load root index, and Drupal generated urls contain apps/drupal.

3 settings.php $base_url = 'http://domainname.com';
No css, but Drupal generated urls don't contain apps/drupal

emjayess’s picture

emjayess commented

@gulliver

I host some sites using 1and1.com shared hosting (Business Linux Package), so I'm familiar with the control panel. There are some tweaks that you will need to make to Drupal's .htaccess file for other things, but what you are trying to accomplish is much simpler and can be done via 1&1's control panel...

1) log in to the 1&1 control panel
2) go to "domains" or "manage domains"
3) check the box of the domain you are working with (the one you are installing drupal for)
4) click the down-arrow for "destination" and choose "edit destination"
5) you'll see a drop-down chooser listing the folders in your account, so choose "/apps/drupal"
6) click 'OK'

It may take a few moments for the changes to actually take effect, but now the domain will be pointing directly at the drupal installation folder as you want it to do, without messing with .htaccess! For reference, this is the equivalent of setting up a virtual host in Apache.

--
matt j. sorenson [ emjayess ]
WEBJAX'd! || twitter.com/webjax
emjayess.net || twitter.com/emjayess

--
Matthew J. Sorenson (emjayess)
d.o. | g.d.o.

gpk’s picture

gpk commented

Yes, this sounds sensible!

gpk
----
www.alexoria.co.uk

gpk
----
www.alexoria.co.uk

gulliver’s picture

gulliver commented

Thanks.
A question...

The site isn't solely Drupal - which has to integrate with other stuff - and I'm thinking that applying that domain destination as a subdirectory will mess-up other things?

I use other apps and static files and having Drupal in its own directory gives flexibility and prevents naming clashes and damage through inadvertent ftp-ing.

-Anti-’s picture

-Anti- commented

>> # Modify the RewriteBase if you are using Drupal in a subdirectory and
>> # the rewrite rules are not working properly.
>> RewriteBase /apps/drupal/
>> #if not enabled, get 500 error

>> # 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]
>> #if not enabled, get 404 error

To be honest, I wouldn't bother doing anything else until you get your basic installation sorted out.
Having the above in your root htaccess shouldn't be necessary, and illustrates that something is screwed.

Is it an fantastico install?
Where do you get an /apps/ directory from? Is that forced by your server or webhost?

If you can, do a manual, fresh install of drupal in a sub-folder 'ROOT/drupal'. Don't touch it's htaccess file.
In your root htaccess, simply have this to start:

Options All -Indexes
RewriteEngine On
RewriteRule ^$ /drupal [NC]

Your installation should work.
At most, you should only have to uncomment: 'RewriteBase /drupal' in the drupal htaccess.

If it doesn't work, IMO something is wrong with your account and you should ask your webhost about it.

emjayess’s picture

emjayess commented

There is just some confusion in this thread concerning how each hosting company treats this kind of setup. Forget about all the .htaccess stuff for the moment, put a fresh copy of Drupal into a directory on your hosting account, and for customers of 1and1.com's shared hosting packages, follow the easy instructions in my previous comment above.

Personally, I use a directory structure like the following:

/www-drupal-6/6.1
/www-drupal-6/6.2
/www-drupal-6/6.3
/www-drupal-6/6.4
/www-drupal-6/6.5

So when I am setting up a new domain, I "edit destination" (again, 1&1-specific) using the control panel for domains, and point that domain at the latest version of Drupal I happen to have installed.

And then I do some fancy multi-site stuff leveraging symlinks and such, but no need to confuse further with that unless & until it is needed ;)

--
Matt J. Sorenson [ emjayess ]
WEBJAX'd! || twitter.com/webjax
emjayess.net || twitter.com/emjayess

--
Matthew J. Sorenson (emjayess)
d.o. | g.d.o.

emjayess’s picture

emjayess commented

After following my earlier instructions on using 1&1's control panel to set up the folder destination for you domain, here are the changes I recommend to Drupal's .htaccess file...

Note that you can make these changes to .htaccess before or after completing the drupal installer. If you make the changes before running the installer, then the installer will detect support for clean urls; but if you wait until after drupal is installed, you'll have to go into Site Configuration > Clean URLs later to get that feature working.

The first change I do is 1 line that tells the system to use PHP5 for my drupal installations, and the second change is uncommenting the RewriteBase line.

Here's a link to what my .htaccess file looks like for 1&1 Shared Hosting. Mind the highlighted lines:
http://emjayess.pastebin.com/f6b1eb2fb

Update: I should note that adding the PHP5 instruction to .htaccess resolves the default register_globals problem I used to get a lot using 1&1 shared hosting. 1&1's PHP runs as CGI rather than as Apache modules, so none of the <IfModule ***> conditions are applicable here. Thus, using the PHP5 environment that 1&1 optionally offers will cure your register_globals blues! Here is the 1&1 FAQ reference.

Enjoy!
--
Matt J. Sorenson [ emjayess ]
WEBJAX'd! || twitter.com/webjax
emjayess.net || twitter.com/emjayess

--
Matthew J. Sorenson (emjayess)
d.o. | g.d.o.

gulliver’s picture

gulliver commented

Thanks.

That of course sorts the problem of the Drupal-generated urls, which are now / and not /apps/drupal/.

And it also opens up other issues.

As I'd mentioned: The site isn't solely Drupal - which has to integrate with other stuff - and I'm thinking that applying that domain destination as a subdirectory will mess-up other things?

So, stuff which is above /apps/drupal/ is no longer browser-accessible - which is exactly why I want Drupal in its own sub-root directory where naming clashes and damage through inadvertent ftp-ing is prevented.

So, back to where we came in... is there a way to install in a sub-root directory and not have that additional path in the Drupal-generated urls?

gulliver’s picture

gulliver commented

The basic install was working fine originally, albeit using unmodded urls.

Nope, not fantastico.

Directory /apps/drupal/ is my own choice.

With all apps in their own directory, I get a cleaner structure with more flexibility.

The site isn't solely Drupal and has to integrate with other apps and static content - and some of the Drupal directories and files naming clashes.

And this way, it's also less-likely that careless ftp-ing will damage stuff.

-Anti-’s picture

-Anti- commented

> applying that domain destination as the /apps subdirectory will mess-up other things?

If you have scripts and files above the /apps root, I don't see how you could reach them
via an address in your browser bar.
Eg. I don't think htttp://domain.net/../an-image-above-apps.jpg would work.

You could probably only *link* to them using relative links:
eg. from a drupal node: img src='/../../an-image-above-apps.jpg'

gulliver’s picture

gulliver commented

As the site isn't solely Drupal, putting Drupal in a non-root folder and then pointing the site root to it means, as you note, that access via browser to stuff not in that folder is affected. And if the other stuff is in that folder, then the naming restriction applies.

emjayess’s picture

emjayess commented

Ok, I understand your goals a little better, I made the assumption you just wanted to run the main site with Drupal, and everything else was secondary... sorry about that!

I am not certain what the best solution is for you. You will want to use your control panel to point your domain back out to the root folder, so you can access your other stuff as before. I do have a few questions that might lead to a good solution...

1) What other kinds of apps are you running, are you shooting for integration? Are you testing stuff or is this a production site? When I use or test other apps, I sometimes set up a subdomain. E.g. I'll set up http://mail.my-site.com and set the destination for that subdomain to a folder like /apps/roundcube.

2) What are your goals for the Drupal part of the site? (Testing? basic content mgmt but no User accounts? other?)

3) With Drupal, do you need the 1st level part of the URL to be open-ended/dynamic? Or can it be constant? That is, can the drupal part of the site always be designated by something that resembles a sub-folder, like "foo":
http://my-site.com/foo/node/1
http://my-site.com/foo/some-other-drupal-content
http://my-site.com/foo/another-drupal-page
Or, do you need it to be open-ended, like:
http://my-site.com/foo/node/1
http://my-site.com/bar/some-other-drupal-content
http://my-site.com/baz/another-drupal-page

Or maybe your goal is to eliminate that part of the URL completely? That could prove to be pretty challenging.

If drupal can always be "foo", or at least fall within a small, pre-determined set of 1st level URL structure, then SymLinks might work for you. Otherwise, probably back to .htaccess hacking or something else.

--
Matt J. Sorenson (emjayess)
d.o. | g.d.o. | WEBJAX'd! | twitter

--
Matthew J. Sorenson (emjayess)
d.o. | g.d.o.

gulliver’s picture

gulliver commented

Thanks Matt. Appreciated.

The long-windedness of what's here is to clarify an overlong thread and possibly help others considering similar issues.

I also couldn't see the advantage of directing the site to a subroot directory to lose the unwanted url portion - surely it'd simply be easier to put Drupal in root to get the same thing of Drupal-generated urls of the form '/etc' rather than '/subroot folder/etc'.

My aim is flexibility and control.

I already use various other apps and static code throughout my sites, and simply want to be able to run one specific section with Drupal rather than build the whole damn site with it - or lose control of my root to an app that only handles part of the site.

So Drupal has to integrate with my existing stuff, not the other way round. That way, my site remains as-is until the Drupal-oriented section which requires integration - thus reducing work, headache, ass-pain etcetera.

Sure, Drupal is a good way to build a complete site. But not for me as I already have a well-defined modular structure with elements of design, html, css, cgi, php and other stuff which works well, is understood by me, and is compatible.

I always use an 'apps' directory, in which are subdirectories for Movable Type, ad-serving scripts, membership handling software, etcetera.

That way, the root is clean and simple; I know what and where everything is; identically-named folders/files clashes are avoided (consider for example a future version of Drupal which could perhaps have additional/differently named folders/files identical to existing non-Drupal ones); and stuff doesn't get inadvertently wiped when upgrading or uploading. Etcetera. Sorry to labor the point.

So, case-made for the requirement to put Drupal 'out of the way' into a specific 'drupal' directory.

Now to the url issue... I simply don't want that subdirectory path to feature in my urls - and there's no reason why it should.

Consider, for example, Movable Type... I place it in '/apps/mt/' etcetera, and when configging specify a local install location and a web url for the content and the job's done. Urls are written relative to the web url rather than the install location.

Actually, consider the same scenario with the many other apps which behave similarly, in writing sensible web-based rather than local urls.

So, having a web-accessible location of domainname.com/news/ is logical and preferable to something like domainname.com/apps/drupal/news. Not an unreasonable requirement.

And sure, I can mod rewrite stuff so a user accesses domainname.com/news/ and views content from domainname.com/apps/drupal/news - no problem... until they use a Drupal-generated link with its full path element.

Grrrrr!

Drupal is good stuff. Powerful, flexible, free. Excellent. And in this instance - stupid. Requiring a root-install just to get better urls is not good thinking. Almost as dumb as Wordpress not allowing you to write the month name in the url. Daft.

Someone please fix it so it behaves more sensibly. [This is the point at which Drupal diehards come-in and attack me. ;-)]

My aim here? Simple: to have things behave better, in a more user-friendly manner.

Sermon over.

Oh yeah, and if someone has a solution to this, please clue-me-in. Thanks.

emjayess’s picture

emjayess commented

I'm a "diehard" (heh), but I'm not going to attack you...

I don't know how to achieve what you are going for, but I'm neither an Apache nor PHP wizard. I've not done much with Rewrite directives or ever really tinkered around with $base_url myself. There very well might be an easy, quick solution. I have used MovableType but that was a couple years ago. Hopefully someone more familiar will chime in. If not, I would encourage you to consider submitting this as a feature request to Drupal core... or perhaps as a contrib module that would make it easier.

I'm not sure if my SymLink suggestion would meet [at least some of] your requirement... if you want to give it a try, SSH into your account and do:
ln -s apps/drupal news

That would get you domainname.com/news running off your drupal installation. But, if you also need paths other than "news" going to drupal, you'd need a symlink for each... and now you are cluttering up your root with symlinks and opening up to FTP overwrites and such... which is exactly what you are trying to avoid.

If I come up with a better suggestion or solution, I'll check back in.

cheers
--
Matt J. Sorenson (emjayess)
d.o. | g.d.o. | WEBJAX'd! | twitter

--
Matthew J. Sorenson (emjayess)
d.o. | g.d.o.

gulliver’s picture

gulliver commented

Thanks Matt.

Good point on the feature suggestion.

And on SymLinks... in considering stuff that I can pass to my clients, some of 'em won't have that facilty,and it IS as you note complex.

;-)

-Anti-’s picture

-Anti- commented

> Now to the url issue... I simply don't want that subdirectory path to
> feature in my urls - and there's no reason why it should.

I just don't think what you're trying to achieve it is possible at all.
The reason is, that browsers don't know anything about directory structure.
The only important thing to them is the url in the browser bar.
And therefore each url to each app *has* to be unique.

> Consider, for example, Movable Type... I place it in '/apps/mt/' etcetera,
> and when configging specify a local install location and a web url for
> the content and the job's done. Urls are written relative to the web
> url rather than the install location.

Are you saying that moveabletype is rewriting the url in the browser bar
to use yourdomain.com/ rather than yourdomain.com/mt/ ?
If it is using: yourdomain.com/... then drupal (and every other app) must
use sub.yourdomain.com or yourdomain.com/sub. That's just the way
browsers work. No way around that.

> And sure, I can mod rewrite stuff so a user accesses
> domainname.com/news/ and views content from
> domainname.com/apps/drupal/news - no problem...
> until they use a Drupal-generated link with its full path element.

Again it is the browser bar url which is important.

An internal drupal link from: domainname.com/apps/drupal/news/todays-news
would be: /apps/drupal/sites/defualt/files/image.jpg

But if the url was rewritten to: domainname.com/news/todays-news
the internal link would be:
/sites/default/files/image.jpg

Similarly, SUB.domainname.com/news/todays-news
the internal link would be:
/sites/default/files/image.jpg

And I think this subdomain method is the only real option open to you.
However, since you're using an abnormal host, I don't know if the following would work:

I would create REAL subdomains in your /apps folder, not with the name of the app, but with the function it performs. Of course the actual folder structure could be the name of the app.

Eg.
website.domain.com (drupal installed into apps/drupal)
blog.domain.com (moveabletype installed into apps/mt)
gallery.domain.com (gallery2 installed into apps/g2)
forum.domain.com (phpbb installed into apps/phpbb)

The apps/drupal or apps/mt part of the path would not appear in the browser url bar.
I have tested this on cpanel-11

Further, because all the urls to all the apps are still at the root (domain.com) without a subfolder in the url, all internal links for all apps should begin simply with / without tying the apps to a specific subfolder (such as /drupal/...).

This would be more inline with the way the internet and browsers are actually intended to work, and you wouldn't have to bang your head against the wall of china, like you're doing now.

The only questions are:
· does 1&1 allow subdomains to be placed in the /apps subfolder?
· do they allow enough subdomains for all your apps?

Now, *after* you have all that set-up, on a normal host (again I don't know if it would work with 1&1, you could use the following ROOT directory's htaccess to stealth ONE of those apps (and only ONE!). In this case, your drupal website installed in the subdomain apps/drupal:

RewriteCond %{HTTP_HOST} ^DOMAIN\.COM$ [NC]
RewriteRule ^$ apps/drupal/index.php [L]
#
RewriteCond %{HTTP_HOST} ^DOMAIN\.COM$ [NC]
RewriteCond %{DOCUMENT_ROOT}/apps/drupal%{REQUEST_URI} -f
RewriteRule .* apps/drupal/$0 [L]
#
RewriteCond %{HTTP_HOST} ^DOMAIN\.COM$ [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* apps/drupal/index.php?q=$0 [QSA]

And in the sites/defaults/settings.php $base_url=http://domain.com

gulliver’s picture

gulliver commented

>Are you saying that moveabletype is rewriting the url in the browser bar
to use yourdomain.com/ rather than yourdomain.com/mt/ ?

I'm saying I install MT at domainname.com/apps/mt/ (or any other path) and the content is accessible at domainname.com/ or domainname.com/other/ or domainname.com/anything/.

It's user-definable in the config file.

Whether 1&1 are good/bad/whatever isn't the issue. (There's less-than-ideal stuff with every host I use and have used.) As a major host, my clients use them and hence the need for a sane solution to something which, as MT show, shouldn't be a problem.

Subdomains have their own issues, and likewise heroic .htaccess voodoo shouldn't be necessary.

-Anti-’s picture

-Anti- commented

> I'm saying I install MT at domainname.com/apps/mt/ (or any other path)
> and the content is accessible at domainname.com/ or
> domainname.com/other/ or domainname.com/anything/.
> It's user-definable in the config file.

Fine. But what do YOU have it set to? That's what matters. If you have it set to domain.com, then EVERY OTHER APP WILL HAVE TO USE A SUBDOMAIN OR FOLDER in it's path. No other app can use simply: domain.com.

In a way, I think moveable type is being very rude and breaking etiquette by doing internal url rewrites like that. If all software did what it is doing, hogging the root domain, none of the software would work! And despite what you think, MT *must* be using mod_rewrite to stealth its subfolder in the url - there is no other way to do it in apache.

> Subdomains have their own issues, and likewise heroic .htaccess voodoo shouldn't be necessary.

OK, I'd like you to explain how a browser is supposed to understand that:

domain.com/news/todays-news is drupal
whereas
domain.com/blog/todays-post is moveabletype

... without 'news' and 'blog' being folders or subdomains

Bear in mind THE BROWSER ONLY KNOWS ABOUT THE URL.
It knows about nothing else and nothing else matters to it.

Hopefully if you try to explain this yourself, you'll understand why you are asking the impossible.

emjayess’s picture

emjayess commented

-Anti-: Fine. But what do YOU have it set to? That's what matters. If you have it set to domain.com, then EVERY OTHER APP WILL HAVE TO USE A SUBDOMAIN OR FOLDER in it's path. No other app can use simply: domain.com.

This is true. A single, top-level domain can't magically have multiple handlers. If MT is handling requests to the root domainname.com, then no amount of voodoo can make Drupal or anything else handle it sometimes too. Kind of a top-level-domain-namespace conflict/clobber scenario.

Likewise, 1st-level segments have a similar story; domainname.com/news/ can't be handled by Drupal some of the time, and MT some of the time.

--
Matt J. Sorenson (emjayess)
d.o. | g.d.o. | WEBJAX'd! | twitter

--
Matthew J. Sorenson (emjayess)
d.o. | g.d.o.