Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.When the security update came out, I updated several 7.51 sites to 7.52 using the SSH sequence of:
drush pm-refresh [rf]
drush cache-clear all [cc all]
drush archive-dump [ard]
drush pm-update [up]I've done this many times before with no issue. But this time, all of my sites suddenly started doing:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator …@testdomain.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.
Apache/2.x.xx at testdomain.com Port 80
I went into CPanel and viewed the logs, and the only thing that showed up was:
“[timestamp] SoftException in Application.cpp:261 : File "/…/index.php" is writeable by group …”
So, in my SSH, I did ls -al and sure enough, all of the .php files had permissions of -rw-rw-r--. So, I did chmod 644 *.php and verified that they were now -rw-r--r--, and then, voila, most of the sites started working again!
One site started generating an error to the effect that PDO was not installed or enabled in database.inc (I forget the exact error and no longer have it copied to my clipboard, and I’m not about to deliberately generate it again). That one turned out to be because a new php.ini had been written to the site root with the previous one renamed to php.ini.bak. The new one was exactly two characters longer than the old one. So, I edited both, and found that two lines had been commented out at the beginning, where I had manually enabled the PDO extension before. Uncommented those, and now that site works as well.
So, apparently the Drupal 7.52 core update script, for whatever reason, is setting the .PHP files to group-writeable, and Apache on my server is apparently set to not serve those for security reasons, generating HTTP 500 Internal Server Error instead. Also, it apparently comments out any lines in a custom php.ini file in the site root that enable PHP extensions, or at least the PDO extensions.
Workarounds:
For HTTP 500 Internal Server Error:
From SSH or other means of getting at a command prompt. do:
chmod 644 *.php
or, if you prefer:
chmod g-w *.php
For PDO extension missing error:
Edit custom php.ini file and uncomment the lines that enable the PDO extension.
Comments
Comment #2
Joel MMCC CreditAttribution: Joel MMCC commentedJust checked another hosting service (non-CPanel-based) where I still have an (inactive) D7 site, and did the update there, and it did not change the permissions of the .php files to group-writeable. Since this may be a server-specific thing, I'm downgrading it to Major.
Comment #3
cilefen CreditAttribution: cilefen commentedDrupal 7.52 makes no permissions changes to files nor does it touch php.ini.
Comment #4
Joel MMCC CreditAttribution: Joel MMCC commentedI know it’s not supposed to, but I know what I saw happen. I’ve used Drupal since the 6.x days and I’ve never seen anything like it before. It happened to multiple sites being updated on the same CPanel server, but not on another site on a non-CPanel but still LAMP server.
Comment #5
Joel MMCC CreditAttribution: Joel MMCC commentedIt occurs to me that it might be a Drush issue. I had recently updated Drush on the CPanel server, but not on the other server.
Comment #6
alisondrue CreditAttribution: alisondrue as a volunteer commentedI updated from 7.51 to 7.52 manually because I'm a newbie. I am still getting the 500 error in Chrome but the white screen of death on Firefox.
"The *****.com page isn’t working
*****.com is currently unable to handle this request.
HTTP ERROR 500"
90% of the time the problem is I somehow messed up the htaccess file. So I replaced that with the old one first - it didn't work.
This may be some evidence that the issue is not isolated to Drush.
Comment #7
cilefen CreditAttribution: cilefen commented@ART_2016: Open a new issue please and include relevant server log entries.
@Joel MMCC If you think this is a Drush issue, I will close this.
Comment #8
cilefen CreditAttribution: cilefen commented@ART_2016 ...unless your issue is fundamentally the same as this one: file permissions changes and an edited php.ini.
Really I do not understand what could have happened in this issue.
Comment #9
Joel MMCC CreditAttribution: Joel MMCC commented@cilefen, I do not think that this is a Drush issue. I stated that it might be a Drush issue, yet @ART_2016’s experience implies that it is not. Until we know for 100% absolute certainty, marking this as “Fixed” is way premature, and wrong anyway if I understand the Status tag rules properly: “Fixed” is only used if something was actually done to repair a real problem. If the problem isn’t real or it works the way it should and the bug reporter merely misunderstood how it’s supposed to work, the proper status is “Closed (works as designed).” If more info is needed, “Postponed (maintainer needs more info)” and so on.
Also, telling @ART_2016 to open a new thread is also premature IMHO. His experience seems similar to mine (I, too, thought it might be
.htaccessand renamed the.htaccessto.htaccess.7.52and the.htaccess.bakto.htaccess, but that didn’t fix it).To @ART_2016: can you get to a Secure Shell (SSH) or Secure FTP (SFTP)? If so, check the permissions on the .php files (especially index.php) in the site root. To do this in SSH, first cd to the site root, then type “
ls -al” and look in the left column. The php files should show “‑rw‑r<strong>‑</strong>‑r‑‑”. If they show “‑rw‑r<strong><u>w</U></strong>‑r‑‑” instead (note the second “w” near the middle of the pattern), then you’re having the same problem I did, and it can be easily fixed: just type “chmod 644 *.php” or “chmod g-w *.php” (and press [↵ Enter] of course).How you’d do this in SFTP depends on the program you use to do SFTP (your SFTP client application). I can’t give you detailed instructions for that.
A good free utility to get you into SSH / SFTP if those are available and enabled on your hosting service is Bitvise SSH Client. You can use it with a password, but I recommend using SSH key pairs with passphrase instead. Takes some setup, but is much easier to use and much more secure.
Comment #10
cilefen CreditAttribution: cilefen commentedHi @Joel MMCC:
Thank you for the info on issue status. Unlike with bugs, support requests are usually marked "fixed" when answered in this queue. Support requests are never marked critical or major.
You opened this as a bug but I converted this to a support request from a bug because, looking at the diff between 7.51 and 7.52, there is no indication the file changes that occur during this upgrade could cause the problems you have seen: files changing permissions (there are none in the diff), edits to php.ini (huh?) and .htaccess (in fact, sometimes .htaccess changes in Drupal releases, but not this time). The problem occurred in the deploy process.
#6 was the first mention of some kind of problem with .htaccess on this issue. It is reasonable to think that is a different problem. @ART_2016 must provide error logs for any idea what is going on. How else would we know this is the same issue? A 500 error is undiagnosable otherwise.
You disagree, and that's fine. I make mistakes just like everybody else. At this stage I usually leave it to others. Good day and good luck with the problem.
Comment #11
Michael G CreditAttribution: Michael G commentedMy input:
1. After standard update procedure to Drupal 7.52.
2. From admin login, ran "run update".
3. received:
The 69.89.31.152 page isn’t working
69.89.31.152 is currently unable to handle this request.
HTTP ERROR 500
4. Reverted back to Drupal 7.51 successfully.
Michael.
Comment #12
cilefen CreditAttribution: cilefen commentedWe need to see what was logged.
Comment #13
Michael G CreditAttribution: Michael G commentedFrom server error log:
[Sat Nov 19 07:42:08 2016] [error] [client 69.89.31.152] Zend Optimizer requires Zend Engine API version 220060519.
[Sat Nov 19 07:42:08 2016] [error] [client 69.89.31.152] The Zend Engine API version 220131226 which is installed, is newer.
[Sat Nov 19 07:42:08 2016] [error] [client 69.89.31.152] Contact Zend Technologies at http://www.zend.com/ for a later version of Zend Optimizer.
[Sat Nov 19 07:42:08 2016] [error] [client 69.89.31.152]
PHP error_log:
/home1/inlowgea/public_html/error_log:
[18-Nov-2016 14:54:33 America/Denver] PHP Warning: require_once(/home1/inlowgea/public_html/includes/bootstrap.inc): failed to open stream: No such file or directory in /home1/inlowgea/public_html/index.php on line 19
[18-Nov-2016 14:54:33 America/Denver] PHP Fatal error: require_once(): Failed opening required '/home1/inlowgea/public_html/includes/bootstrap.inc' (include_path='.:/usr/php/56/usr/lib64:/usr/php/56/usr/share/pear') in /home1/inlowgea/public_html/index.php on line 19
Michael
Comment #14
cilefen CreditAttribution: cilefen commented@Michael G: In your case, the Drupal core file /home1/inlowgea/public_html/includes/bootstrap.inc was not present. The distribution downloads of 7.52 contain includes/bootstrap.inc. What was the upgrade procedure you followed?
Comment #15
Michael G CreditAttribution: Michael G commentedcilefen:
The file /home1/inlowgea/public_html/includes/bootstrap.inc was present..
I tried now to clear google chrome browser data and repeated the standard update procedure.
All is working fine !
Thank you for all efforts,
Michael.
Comment #16
plato1123 CreditAttribution: plato1123 commentedSame issue I think, did Drush pm-update Drupal and once it updated from 7.41 to 7.54 white screens. Investigating... subscribing.
I'm also seeing Zend errors as Michael did above. edit: I was able to get Bluehost tech support to reset the zend version. Apparently their security modules ioncube and/or SourceGuardian require a specific zend version and either Drush or Composer updated the version.