Hi everyone,

I get this error message after updating Drupal 7.14 to 7.24 when I browse to the site (that means, homepage and just any other page tried).

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, support@XXXXX.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

I have seen this page: https://drupal.org/node/416906 but so far to no avail. I tried uncommenting the RewriteBase / in .htaccess, but that doesn't seem to do much.

Can someone help me? Please note that I'm but an amateur and by no means a software engineer or professional programmer. Just finding my way to Drupal and learning on the way.

EDIT: I also can't seem to access the forum (not Drupal) that is installed in a subdirectory. I guess this has something to do with some kind of access or permissions?


technobrarygeek’s picture

I just "updated" from 7.22 to 7.24 if going from a functional site to "500 Internal Server Error" is an update. lol


Castus’s picture

I (temporarily) solved the problem by replacing the .htaccess file by my old one. However, I presume there have been changes to that between 7.14 and 7.24. Where can I find these changes? Thanks in advance!

ar-jan’s picture

You can read the release notes for each release. Of course if you skip so many releases that's quite a lot of work. In this case you could do a diff between your old .htaccess and Drupal 7.24's, then add things that you customized in your old version back into the new .htaccess (things like uncommenting "RewriteBase /").

Castus’s picture

I feared for this, reading all the release notes.

How do you "do a diff", as you say? I suppose that's compare the two for what's different?

Castus’s picture

I compared the two files and made the changes, testing each change. The problem seemed to be here:

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

# Follow symbolic links in this directory.
 Options +FollowSymLinks

I commented out both, because with either one uncommented, I got a 500 error. What consequences has this?

ar-jan’s picture

If you look at Drupal 7.14's .htaccess, you'll see that both these options were already there, so this must be a symptom of another problem (that you worked around previously by changing the .htaccess).

Options -Indexes is to prevent apache from showing a directory listing, e.g. when a page is not served by Drupal's index.php. This is good for security/privacy.

Options +FollowSymLinks may also be needed for some things to work properly, though I'm not sure of the top of my head what for.

Can you check the permissions for your public_html folder (or whatever your document root folder is named), and see if it has overly broad permissions? I've seen some hosting companies where 775 will give a 500 error, try 755 instead in that case.

ar-jan’s picture

A diff shows the contents of two files side-by-side and highlights the differences. For Windows, I think e.g. Notepad++ has a plugin to do this; on Linux I use Meld. There are many other programs you could use.

pixelsnap’s picture

Since updating to 7.24, I am getting memory spikes which overload the server (shared hosting at anhosting/midphase) and give "Internal Server Error 500" messages. Anyone else get this after the update? Everything worked fine before, and never got such errors. I thought it might have something to do with cron, so I set automatic cron runs to "Never" but the problem persists. Any experts here? ;-)

John_B’s picture

I have not seen other reports of this. You might get some clues by running Devel module with the Query Log on.

pixelsnap’s picture

I installed devel and had a look, but I'm no expert on this stuff unfortunately. I found a "php5_error_log" file though, in the root directory of all of my various add-on sites on that main hosting package I have (all very low-traffic installations, with no video, no streaming, very low image content, etc.) AND those logs make repeated references to being unable to "load dynamic libraries" which appear to be server issues and NOT my Drupal sites. Here are two such lines, from the end of a looooong list of identical declarations:

[14-Dec-2013 07:19:18 America/Denver] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20100525/uploadprogress.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20100525/uploadprogress.so: cannot open shared object file: No such file or directory in Unknown on line 0
[14-Dec-2013 07:19:18 America/Denver] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20100525/memcache.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20100525/memcache.so: cannot open shared object file: No such file or directory in Unknown on line 0

Any ideas? The folks at the hosting company are giving me the runaround on this, but I have a variety of slightly different Drupal 7 sites on other hosts (including some here in Switzerland) without a single message like this, although all the core and module versions are the same. It seems very odd that ALL of the installations (six separate add-on sites and the main host installation) only show this problem at that one single hosting company, and nowhere else... Thanks for any advice on this.

John_B’s picture

You have to sort them out one by one. Drupal likes to have upload progress, you can ask your host to install it. The reference to memcache suggests one of the sites has memcache module installed (which it should not if it is not on the server).

The admittedly higher cost of a real Drupal specialist host is excellent value in the time and effort it saves, as well as for providing better speed. I suggest moving hosting.

If there is really a connection between the update and the memory spikes (which I take it is suspected but by no means certain) I doubt these error messages point you to it, but they should be fixed.

pixelsnap’s picture

Thanks for the suggestion. None of the sites involved are using the memcache module, but the hosting company responded last night, with a useful detail, finally. As a quick aside, I had specifically chosen them because they were listed on drupal.org as a "Drupal-friendly" host... Apparently, the server hosting my Drupal sites was just-recently upgraded to PHP ver. 5.4.22. They said the error messages indicate that my "software" (Drupal 7, fully updated) was trying to access files no longer used in 5.4.22 and that was the problem. I guess they are no longer "Drupal-friendly" then...

John_B’s picture

The slightly more expensive Drupal only hosts as Drupion.com, hotdrupal.com, Civihosting.com shoulf be ok. The impression created by this site that listed hosting companies are checked and suitable is misleading.

ar-jan’s picture

I'm using it for various D7 sites. I even tested D6 sites on it without major issues. Maybe some contrib modules are less compatible, but all issues I've seen are about notices, not things actually breaking completely.

eva’s picture

Though I've off and on "played" with Drupal, I am only a newbie fascinated with Drupal and trying to get it to work. I've been successful at putting up various sites over the years through much trial and error and help from the community. I'm now coming back to Drupal...

I've had difficulty getting the core 7.24 Drupal download to work. I'm not sure I followed the directions accurately in terms of manually editing the .htaccess file (see below). I've searched quite a bit to identify possible solutions and now I'm at a dead end, and am having similar issues as other posters on this thread.

I'm on a shared hosting environment with the following details (and I will be shifting to a Drupal friendly ISP in the New Year):

PHP 5.3
MySQL 5.5.32
mod_rewrite loaded on server
i do have access to my tmp folder

I've already asked and I'm told the memory limit has been upped to 256MB (I just asked for it to be increased, and that's what they told me).

I ran into the "500 Internal Server Error" when getting to the last step of the installation. After much searching, I contacted my ISP and tried to get help there. The technician upped the memory, and nothing immediately changed. When I went back to refresh after a few minutes, my site suddenly appeared and I was able to access the admin functions. I wasn't sure what changed.

When I went to configure the site and enable clean urls, I discovered that I could not enable them, and that one possible solution was to edit the .htaccess file. When I opened my public_html file, I found that the .htaccess file had been renamed to .htaccess_old and that it was basically removed from serving its purpose. At the same time, the site was functional. In the moment I put the .htaccess file back into commission, the site broke. I am unable to figure out what portion of the .htaccess file contributed to the break. However, after searching the Drupal site, I thought it might be that mod_rewrite was not loaded on the server. ISP staff confirmed that it is loaded.

Any thoughts about what might be breaking the site (and how to get the core modules up and running?

Thanks in advance,

I'm not sure I followed the directions correctly for editing the .htaccess file with the snippets that needed to be manually added to public .htaccess, the tmp, and file .htaccess (the following is public .htaccess):

# Apache/PHP/Drupal settings:
# Turn off all options we don't need.
#Options None
#Options +FollowSymLinks

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006

  # Override the handler again if we're run later in the evaluation list.
 SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003

# If we know how to do it safely, disable the PHP engine entirely.

  php_flag engine off

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
  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_value memory_limit 256M

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  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.
<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

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # 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
  # <DirectoryMatch> 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.
  <IfModule mod_headers.c>
    # 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]

    <FilesMatch "(\.js\.gz|\.css\.gz)$">
      # 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
John_B’s picture

This should probably be a separate thread. Anyway I would compare the two .htaccess files and list the differences. Hopefully the one you have is broadly similar.

This bit

# If we know how to do it safely, disable the PHP engine entirely.
  php_flag engine off

is not part of the .htaccess which comes with Drupal core (I just downloaded a fresh copy before writing this answer to double-check). I would use that default file which comes form the version of Drupal available on this site as a starting point.

For development work best not waste time battling with an unsuitable server. Just download Drupal onto a laptop (if it is not linux you can use a VM or download Acquia Dev Desktop) and work there.

eva’s picture


I had put in a help request with my ISP. Ironically, just as I read your post, the email came up saying the exact same thing. Trying to figure out what to add manually into the .htaccess file in order to get things working was a little confusing. Thank you for quick reply and your help.

Much appreciated,

mattbk’s picture

Setting permissions to 755 worked for me, but I'm not sure if this was a particular host issue or not.

Das123’s picture

I had an issue where the server had been compromised. After updating (to 7.34) the server was giving a 500 error that none of the .htaccess solutions would work for.

I had a look at the error log (in cPanel as this is a shared host and the actual error logs are hidden away) and it showed an error with group write permissions on the index.php file.

Looking into it further I noticed that many files had chmod permissions of 664 and directories of 775 (Group write permissions turned on). I recursively changed the permissions to 644 for files and 755 for directories and that solved the 500 error.

Jaypan’s picture

oprisk1’s picture

There is some conflict created with Apache when using the distributed .htaccess file. I worked around this problem temporarily by removing the .htaccess file from the root directory (ie. Drupal.7.3.4) structure created when unzipping the compressed download.
Although the 500 error requires further investigation, it appears there is a conflict between installation root directory .htaccess and the apache http.conf file.
I have two installations where one generates the 500 error, while a second installation with the distribution .htaccess file present does not.
My environment is a Mac OS X 10.10 with Apache/2.4.9 (Unix) PHP/5.5.14

John_B’s picture

Normally the causes of these things are flagged up in the Apache error log.

fhdrupal’s picture

The following .htaccess settings worked for me. The following part in public .htaccess should match the files directory .htaccess.

public htaccess:
# Follow symbolic links in this directory.
Options +SymLinksIfOwnerMatch

files directory htaccess:
old settings:
Options +FollowSymLinks

replaced with:
Options +SymLinksIfOwnerMatch

After updating to the new drupal version 7.34 images won't appear, because new drupal update had a little different from the old one.
After updating to the above settings my images are shown now. Hope this help.

ecsabi’s picture

I spent half a day to find a solution. I tried quite a few workarounds and tests.

Only your suggestion worked.

Thank you very much.

carvingpixel’s picture


carvingpixel’s picture

*Resolved my own Internal 500 error finally, skip to bottom of post*

Found this thread looking up 500 internal error which I am getting with installing Drupal 7.39. Had the same with new Drupal 8. Followed several sites and suggestions for changing permissions, etc. Running a windows IIS setup. Added the app pool user, gave rights, etc. Still had that issue.

After reading this blog, I tried the older version of Drupal of 6.37 offered on the download page. it worked flawlessly.


Version Date
8.0.0-rc1 2015-Oct-07
7.39 2015-Aug-19
6.37 2015-Aug-19

Looking at those differences seems to be the key here for us at least. Just wanted to add in what we have found and seen so far. Will try to figure out those differences and what's missing so we can run the latest version of 7.

Our Resolution: (hope it helps)

Installed drupal 6 on the server instead of 7 first. Followed along and resolved many of the errors that came up in the process. One of which was to add a web.config file under windows32 directory where IIS is installed and where the mod rewrite program gets installed. This is similar to a .htaccess file but on the windows system for iis instead. After finding that text we needed, created the file, added it there, it resolved some issues for 6. I then realized that was the main error that it kept talking about for the Internal 500 error, the web.config file issue. So I went back and tried the install again, and it was there appearing and resolved.