By Avatar on
A headache for several days now. It seems the rewrite engine is causing an internal server error. The weird thing was that the site is ok for a while, but then nowadays I keep getting this error when trying to log in. I don't think I did anything between now and then except adding more content to the site.
I browsed the forums and it seems to be a common problem. I tried everything I think: uncommenting # RewriteBase / , commenting out Options +FollowSymLinks , adding AddType x-mapp-php5 .php despite the fact that I do run php5 I think..to no avail
I don't know what could be wrong so if you could tak a look at my .htaccess and give me suggestions, i'd be grateful
#
# Apache/PHP/Drupal settings:
#
# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl|svn-base)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template|all-wcprops|entries|format)$">
Order allow,deny
</FilesMatch>
# 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
# Force simple error message for requests for non-existent favicon.ico.
<Files favicon.ico>
# There is no end quote below, for compatibility with Apache 1.3.
ErrorDocument 404 "The requested file favicon.ico was not found.
</Files>
# Set the default handler.
DirectoryIndex index.php
# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.
# PHP 4, Apache 1.
<IfModule mod_php4.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
php_value mbstring.http_input pass
php_value mbstring.http_output pass
php_value mbstring.encoding_translation 0
</IfModule>
# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
# Enable expirations.
ExpiresActive On
# Cache all files for 2 weeks after access (A).
ExpiresDefault A1209600
<FilesMatch \.php$>
# 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
</FilesMatch>
</IfModule>
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# 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/...)
# adapt and uncomment the following:
# RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
# RewriteRule ^(.*)$ http://www.example.com/$1 [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 and adapt the following:
# RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
# RewriteRule ^(.*)$ http://example.com/$1 [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 /
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>
# $Id: .htaccess,v 1.90.2.4 2009/12/07 12:00:40 goba Exp $
Comments
Just a point to note you can
Just a point to note you can browse the site normally. Only if anyone tries to log in where the error appears
Any hope????
Any hope????
Still waiting!!! :(
Still waiting!!! :(
some things to try
where are you trying to log in from - /user or the login block?
do you have clean URLs enabled, and if so, does disabling them get logins working?
do any other form submissions (like search) cause a 500 error?
1) Always tried from the
1) Always tried from the login block. I also tried from the ?q=admin page and the same error appeared. Not sure what you mean by "/user"? Do you mean www.mysite.com/user ? If so, then I just tried it now and the error again appeared
2)Yes, Clean URLs is enabled , but I can't get to disable it since I can't even log as admin. The only way could be is to remove the mod folder from my server, but this could cause problems. I did try commenting out the "rewriteengine on" line and the error disappeared , but ofcourse I wasn't able to navigate to any page on the site plus I couldn't log in as well. Clicking any link or submit button just redirects me to the homepage as a guest
3)Yes, just tried it now and using the search mod causes the same error. I have also a contact us form and again submitting data outputs the same error.
so it's a bigger problem than
so it's a bigger problem than just your login, your form submissions aren't working.
to bypass the clean URLs, try going to www.mysite.com/?q=user and logging in. if that works, it probably isn't mod_rewrite.
you can ignore clean URLs for any page by using /?q= in front of the regular path.
I still couldn't log in from
I still couldn't log in from that page!!
So what's causing the forms not to work??
I have seen this error before
I have seen this error before many a time in a multi-host scenario, are you running a public_html folder in a user's home directory? is the ownership on the files okay? what does an ls -la return on those files or directories?
It should return a username:apache for example.
are you storing your files in a srv folder or /var/www/html/your_drupal_dir?
Also have you checked Apache or your web daemon logs? in Fedora, RHEL or CENTOS its logs are in /var/logs/httpd/ ??
I am kinda noob here so I
I am kinda noob here so I really have no idea what you're talking about :)
Hosting is shared, godaddy hosting to be precise
There is no folder called public_html in the root directory
Is -la : I have no idea what's that or what to do!!
srv folder or /var/www/html/your_drupal_dir?: again no idea. I just have all the drupal files in a root directory and thats it.
I can't access my server logs. I have to pay more and upgrade my hosting to be able to do so.
what I also don't get is that
what I also don't get is that the site was working fine at first. The site is till in production with only 4 articles added. This problem only appeared after adding the 4th article.
Are you running SE-linux? if
Are you running SE-linux? if so have you tried stopping it temporarily? EDIT: this usually cannot be done now that we know your in shared hosting... you usually do not have the power to do this.
Godaddy hosting from what I have heard has a reputation of being far from stellar (not good, but I do not know) perhaps you could phone their support line and get assistance?
Godaddy checked and replied
Godaddy checked and replied :
I have a point to note. I got this error more than a week ago and i had to restore the database from a backup. Following this, everything worked fine. But now I got the error again and I didn't do anything to the database except adding more articles to the site!! I guess if I did another restoration, things will be fine, but for how long??!! I am considering doing the restoration once more then logging to the drupal admin and disabling the clean urls mod then removing the htaccess and following up!!