[SOLVED] Unable to access new install (D7 Commerce KickStart) in sub-directory of old install (D7 vanilla)

Posted by AlanQ on November 3, 2012 at 7:18pm

I have an instance of Drupal 7 in my top-level domain -- it works fine.

I have installed Drupal 7 in a sub directory -- for testing purposes.

When I try to access TLD/sub/install.php
the top-level Drupal captures the request
and I get the error message:
"The requested page "/sub/install.php" could not be found."

I believe that I have followed the install instructions correctly:
All files uploaded
/sub/sites/default/default.settings.php copied to /sub/sites/default/settings.php
settings.php given permissions 666
Empty database is ready.

I have previously succeeded in doing this on the same server using Softaculous,
so it must be something I've done wrong or forgotten to do.

I must install manually this time because it's a special/modified version of D7 -- namely Commerce KickStart.

As I try to dig myself out of this hole, could someone point me to my most likely error?
Or a selection of several :)
Many thanks.

Comments

=-=

Posted by VM on November 3, 2012 at 7:29pm

settings.php is supposed to be 777 so that drupal can write to it during install. then you can make settings.php 444 after install, if drupal doesn't do it on it's own.

however, the bigger issue is getting the 1st install to ignore the subdirectory that the second install resides in. see: http://drupal.org/node/30334

Thank you, VM settings.php

Posted by AlanQ on November 3, 2012 at 9:44pm

Thank you, VM

settings.php changed to 777
and

  # stuff to let through (ignore)
  RewriteCond %{REQUEST_URI} "/sub/"
  RewriteRule (.*) $1 [L]

added naively to .htaccess

I'm still getting the same PageNot Found error.

Anything else I can try?

=-=

Posted by VM on November 3, 2012 at 10:10pm

just to clarify, you added the rewrite to the main site .htaccess file?

SOLUTION

Posted by AlanQ on November 4, 2012 at 3:45pm

Yes, I did.

And I now have the solution to the problem :)

I did some searching and found that some people prefer to use a sub-domain rather than a sub directory
ie sub.TLD/ rather than TLD/sub/
which, in some cases can fix this kind of problem.

I had trouble setting up the sub-domain and, during messages to my web service provider, was given the answer to the overall problem:

The .htaccess file in the sub-directory (sub-domain) contained a directive that they disallow for security reasons.

By replacing
+FollowSymlinks
with
+SymLinksIfOwnerMatch
it now works!

See https://httpd.apache.org/docs/2.0/mod/core.html#options for details.

Note: The Rewrite rules added to the TLD .htaccess file makes no difference. It works with them in place and it works now that I have removed them.

Thank you again VM.
I shall mark this thread as solved.