I get a 500 internal server error at a new site which is a fresh 7.34 ftp install. I haven't even run the install script yet.

My other site running earlier versions (7.24) versions of Drupal are working. Same server, same folder. I tried the suggested edits on the .htaccess file, even cut and paste the 7.24 .htaccess code into th 7.24 .htaccess. The old sites keep running and the new one is a 500.

I'm at a loss as what to do next. Gonna sleep now. Hopefully someone has a suggestion in the morning. Thanks!

Comments

John_B’s picture

It is not unusual for an ftp upload to partially fail, especially if you unpack the archive before uploading.

I would re-upload the code, preferably as a single archive then unpack it. If possible, drop all tables in the database and start the install over.

Scratch that - I did a Drupal 7 install today, and what I do personally is use drush.

drush dl drupal gets you the code in a few seconds.

If you are already in document root, then

cd drupal-7.34
mv * ..
mv .* ..
cd ..
rm -r drupal-7.34
drush site-install --db-url=mysql://password@localhost:dbname --account-name=dbuser --account-pass=dbpassword

replacing db details with the details of the database user (and optionally the database) you set up earlier.

It only takes a few seconds to make a Drupal site this way. Having said that, it does assume you have or are willing to install drush. If your hosting supports Drupal properly, it is already installed.

You can check if your web server is basically working for a php site by making a phpinfo.php file (

<?php 
phpinfo();
?>

)
and visiting your URL followed by /phpinfo.php. If the page loads with details of your setup, delete the file, knowing that basically the server is good to go, and ready to accept a Drupal install.

Whatever your preferred installation method, the reason for the 500 error should be in your Apache error log. If you created the server with Virtualmin you will probably find the error log pointing to the FollowSymLinks error https://www.virtualmin.com/node/24554 which requires to hack Drupal's .htaccess or Virtualmin's Apache .conf file.

elaine_t’s picture

Hello there,

I'm having similar problem as jasonmcd, but the other way around. My new drupal install runs fine, but not my old drupal site. The drush used to work fine on the old site, not sure what's changing that make it produce 500 internal server error.

I've checked on files/folders ownership and permission. I used the .htaccess file from new site and didn't help either.

Error log:
PHP Parse error: syntax error, unexpected T_FUNCTION in /olddrupal/sites/all/modules/webform/webform.module on line 4570
PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in ~/drush/includes/drush.inc on line 1652
PHP Warning: fwrite(): supplied argument is not a valid stream resource in ~/drush/includes/output.inc on line 34

Any clue on how to fix it will be greatly appreciated.

Many thanks in advance!

John_B’s picture

Hard to say without more information. Are you confident the site has always had security updates applied promptly and is not hacked?

Best report the version of php on the server, and the version of webform you are using.

Overwriting webform with a fresh copy of the same version may fix it, if the file has somehow got corrupted.

Also I suggest checking whether you have kept drush up to date as these notices look like an old drush issue.

elaine_t’s picture

Thank you, John.

elaine_t’s picture

BTW, it works now. I disabled webform module, then it complained for other modules. Once I disabled a few modules, drush works fine now. Thx anyway.

ankit08’s picture

Can you show the .htaccess file error 500 means reconfiguration in server settings therefore it may be by .htaccess that conflict with your hosting account setting.

jasonmcd’s picture

Thanks, everybody. Apparently making the FTP transfer as root messed up the UID settings. I was able to reset permissions and everything's working. I appreciate everyone's assistance!

John_B’s picture

Most servers have root FTP login disabled for security reasons.

nodrigo’s picture

Check your security server.

mddia’s picture

go to settings.php and turn $update_free_access to TRUE;

and then run update.php.