non Drupal pages can't be viewed

Carolina Tiger Rescue's picture

I installed Drupal 7 on the same server as our e-commerce site. Our ecommerce vendor said this shouldn't cause any problems, and if it has, they've been easy to correct.

However, I created another folder in the root directory to add a page to our existing website (nonDrupal), and when I try to go to that page, it shows "Site under Maintenance".

I've tried modifying the .htaccess to exclude this folder, but can't get this to work

how do I tell Drupal this doesn't belong to it?

Comments

Have you created a page like

dpickerel's picture

Have you created a page like newpage.html? What is the extension on the new page? And have you checked permissions on that directory, it sounds like you might be getting a 404 not found.

if there's a real file there Drupal should ignore it. I had problems with the Deny All that drupal wanted in the new /sites/default/files directory, but other than that I haven't noticed a difference. I do that all of the time to create test and migration scripts.

the file name is

Carolina Tiger Rescue's picture

the file name is register.php

I don't think it's a 404 error- because I get the Site under maintenance message (standard response from test site), and I do have a separate 404 file that works fine.

The directory structure looks like this:

  • BigCatSafari
    -register.php
  • cgi (this is the repository of our e-commerce)
  • sites (this is where all my Drupal is)
    • all
      • libraries
      • modules
        -themes
  • .htaccess
  • donate.php (this is a donate page used on the existing site- it works fine)
  • 404.html

it's a php file

Carolina Tiger Rescue's picture

the file name is register.php

I don't think it's a 404 error- because I get the Site under maintenance message (standard response from test site), and I do have a separate 404 file that works fine.

The directory structure looks like this:

  • BigCatSafari
    -register.php
  • cgi (this is the repository of our e-commerce)
  • sites (this is where all my Drupal is)
    • all
      • libraries
      • modules
        -themes
  • .htaccess
  • donate.php (this is a donate page used on the existing site- it works fine)
  • 404.html

notes

Kyle Skrinak's picture

Like your e-commerce vendor suggests, this should not be a problem.

I did two quick tests:

create a simple html file in the root of a default drupal site
http://rootdirtest-skrinakcreative.rhcloud.com/1.html
-- works fine

And then create a simple php page within a subdirectory off the drupal root:
http://rootdirtest-skrinakcreative.rhcloud.com/snookums/phpinfo.php
-- works fine

No problems, as I expected.

Can you check your log files? It should show attempts by apache to serve from that location. I'm also wondering how your .htaccess is different from the Drupal default — or did the e-commerce software set the .htaccess file?

You didn't ask, but the problem with this workflow will be when it is time to update drupal. You might want to think about alternative ways to have your ecommerce and drupal directories separate.

ah- you know, I did update

Carolina Tiger Rescue's picture

ah- you know, I did update Drupal that last coworking day, and I've created the BigCatSafari directory since then, but I had another directory with working phps (I omitted for simplification)that I was working in just before the update. It's has been working fine.

I have the default .htaccess except I added a reference at the beginning for a 404.html file, and under ReWrite Engine On I called the BigCatSafari. I mostly tried some of the stuff here: http://www.thesitewizard.com/apache/access-non-drupal-folders.shtml

Well- if it's because of the update, what can I do?

What are you using for hosting?

Kyle Skrinak's picture

Shared hosting, self-managed, or?

What are you using for hosting?

Kyle Skrinak's picture

Shared hosting, self-managed, or?

don't cringe- it's godaddy.

Carolina Tiger Rescue's picture

don't cringe- it's godaddy. :)

I have some control over the settings through their web interface.

I think I'll try recreating the directory with a different name tomorrow when I get back to work and see how that goes

sounds like there's something

dpickerel's picture

sounds like there's something funny in your .htaccess to me. Drupal should normally be called only if a real directory path and file can't be found. That's why i was thinking permissions, apache may not have read rights in that directory so it's the same as not being there.

if you want to post your .htaccess i can give it my best guess. there shouldn't be anything sensitive in there.

camelCase

shotokai's picture

have you tried NOT using camelCase for the directory name? dpickerel is right in saying that if Drupal is being invoked, then Apache does not thing the directory/file that you are asking for is part of the file system. Depending on the Apache setup, camelCase can present an issue in this respect.

Your first issue here is apache - Drupal should not be invoked at all if you request a directory/file combination that actually exists.

Do you happen to have CPanel,

dpickerel's picture

Do you happen to have CPanel, especially under WHM? Ownership permissions are a real bugger because of the way they run each apache thread as its own owner. I think group permissions has to be "nobody" or nothing can be read. I think it's the mod_ruid2 module.

It's caused me a few sleepless nights. Now i only create files and directories in the ftp account to make sure i get them right.

new directory

Carolina Tiger Rescue's picture

The "new directory" strategy did not work. I created a new directory, BCSafari, in the html root, and oddly it displays the body of the file, but also includes the "site under maintenance"

http://savannastation.carolinatigerrescue.org/BCSafari/default.html - see for yourself (I would have expected one or the other, not both)

I use SSIs for the header and footer- these are not displayed on the link above.

my .htaccess- the only change I have made is the Rewrite condition for the BigCatSafari folder after ReWrite Engine On

ErrorDocument 401 /401.html
#
# Apache/PHP/Drupal settings:
#

# Protect files and directories from prying eyes.

Order allow,deny

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Make Drupal handle any 404 errors.
ErrorDocument 404 /index.php

# Set the default handler.
DirectoryIndex index.php index.html index.htm

# Override PHP settings that cannot be changed at runtime. See
# sites/default/default.settings.php and drupal_environment_initialize() in
# includes/bootstrap.inc for settings that can be changed at runtime.

# PHP 5, Apache 1 and 2.

php_flag magic_quotes_gpc off
php_flag magic_quotes_sybase off
php_flag register_globals off
php_flag session.auto_start off
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_flag mbstring.encoding_translation off

# Requires mod_expires to be enabled.

# Enable expirations.
ExpiresActive On

# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600

# Do not allow PHP scripts to be cached unless they explicitly send cache
# headers themselves. Otherwise all scripts would have to overwrite the
# headers set by mod_expires if they want another caching behavior. This may
# fail if an error occurs early in the bootstrap process, and it may cause
# problems if a non-Drupal PHP file is installed in a subdirectory.
ExpiresActive Off

# Various rewrite rules.

RewriteEngine on
RewriteCond %{REQUEST_URI} !^/BigCatSafari/.*$
# Set "protossl" to "s" if we were accessed via https://. This is used later
# if you enable "www." stripping or enforcement, in order to ensure that
# you don't bounce between http and https.
RewriteRule ^ - [E=protossl]
RewriteCond %{HTTPS} on
RewriteRule ^ - [E=protossl:s]

# Make sure Authorization HTTP header is available to PHP
# even when running as CGI or FastCGI.
RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# Block access to "hidden" directories whose names begin with a period. This
# includes directories used by version control systems such as Subversion or
# Git to store control files. Files whose names begin with a period, as well
# as the control files used by CVS, are protected by the FilesMatch directive
# above.
#
# NOTE: This only works when mod_rewrite is loaded. Without mod_rewrite, it is
# not possible to block access to entire directories from .htaccess, because
# is not allowed here.
#
# If you do not have mod_rewrite installed, you should remove these
# directories from your webroot or otherwise protect them from being
# downloaded.
RewriteRule "(^|/)\." - [F]

# If your site can be accessed both with and without the 'www.' prefix, you
# can use one of the following settings to redirect users to your preferred
# URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
#
# To redirect all users to access the site WITH the 'www.' prefix,
# (http://example.com/... will be redirected to http://www.example.com/...)
# uncomment the following:
# RewriteCond %{HTTP_HOST} .
# RewriteCond %{HTTP_HOST} !^www\. [NC]
# RewriteRule ^ http%{ENV:protossl}://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
#
# To redirect all users to access the site WITHOUT the 'www.' prefix,
# (http://www.example.com/... will be redirected to http://example.com/...)
# uncomment the following:
# RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
# RewriteRule ^ http%{ENV:protossl}://%1%{REQUEST_URI} [L,R=301]

# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]

# Rules to correctly serve gzip compressed CSS and JS files.
# Requires both mod_rewrite and mod_headers to be enabled.

# Serve gzip compressed CSS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.css $1\.css\.gz [QSA]

# Serve gzip compressed JS files if they exist and the client accepts gzip.
RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{REQUEST_FILENAME}\.gz -s
RewriteRule ^(.*)\.js $1\.js\.gz [QSA]

# Serve correct content types, and prevent mod_deflate double gzip.
RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1]
RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1]

# Serve correct encoding type.
Header set Content-Encoding gzip
# Force proxies to cache gzipped & non-gzipped css/js files separately.
Header append Vary Accept-Encoding

You can see the hosting controls I might have to work with from this screencapture:
http://carolinatigerrescue.org/downloads/2014-03-04%20Godaddy%20hosting%...

what else shall I try?

DOH

Carolina Tiger Rescue's picture

I thought I'd been careful about this, but apparently the error is because Apache is case-sensitive. I had failed to include capitalization in my URL.

(hanging head in shame)

We've all done it...

shotokai's picture

I would recommend that you always use lowercase for everything and decide on whether you want to use hyphens or underscores for joins and then always do it the same way. Case sensitivity in Apache varies based on your environment, as does the ability to do things like interpolate camelCase to lower_underscore. Avoid confusion and name_all_your_directories_the_same_way ;-)