Magento on admin order create and frontend checkout returns 500 error after update to 1.9.4.2

Question

Hi guys I have just updated my site to 1.9.4.2. But when I attempt to create an order in admin I get a 500 error. Same happens on frontend onepage checkout.

Tried turning errors on nothing shows.

For enabling error reporting, I did the following:

In Index page change the following:

error_reporting(E_ALL | E_STRICT);

to

error_reporting(E_ALL);

Set $_SERVER['MAGE_IS_DEVELOPER_MODE'] = true

and uncomment this line

#ini_set('display_errors', 1);

In Errors folder rename local.xml.sample to local.xml.

In the .htaccess file I added

SetEnv MAGE_IS_DEVELOPER_MODE=true
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag  log_errors on
php_value error_log  /var/www/html/mag19/mag19errorphp.log

The update works well on my local site and no errors. But, on the prod site which is nearly like for like as local site, it throws the 500 redirect error. Refreshing the page on frontend checkout, before the http 500 error is shown, whilst refreshing, I can shortly see the red cross for error on chrome dev tools. This however disappears before you get to see the error as the http 500 error kicks in.

**

• UPDATE 05/07/19: Been awhile and and I am none the wiser as to why this happened. I have reverted back down to 1.9.4.1 and all is working well.

  Backtracing, by carrying out each new change individually. I believe I have stumbled across the root cause. It has to be one of the changes in the Authorizenet module in core. As soon as I carry out those the afore stated error occurs.

Why this module causes issues is beyond me. We do not even use it!!

**

Files changed in Authorizenet module:

**

• Update 08-07-19: The validate function in the Directpost.php model file looks to be the issue cause;

  public function validateResponse()
  {
      $response = $this->getResponse();
      $hashConfigKey = !empty($response->getData('x_SHA2_Hash')) ? 'signature_key' : 'trans_md5';
  
      //hash check
      if (!$this->getConfigData($hashConfigKey)
          || !$response->isValidHash($this->getConfigData($hashConfigKey), $this->getConfigData('login'))
      ) {
          Mage::throwException(
              Mage::helper('authorizenet')->__('Response hash validation failed. Transaction declined.')
          );
      }
      return true;
  }
  

**

**

• UPDATE 10/07/19: I have looked into this further and I believe the issue is because production server runs 5.4.x whereas local server is on 5.6.x. Whereby, as per the php official documentation:

Note: Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error. In other words, the following will not work: empty(trim($name)). Instead, use trim($name) == false.

Thus, when PHP is going to parse this, it will result in a parse error.

Now, as per Magentos' official documentation they "are" supporting:

Whereby, 5.4 support is listed as supported but evidently it does not support this clearlly. **

Answer 1

The problem is solved! namely this was occurring due to incompatibility between PHP 5.4.16-46.el7 and Magento 1.9.4.2.

Yes! their official document states this PHP version is supported. But certain segments of code in their Authorizenet core module are written in a coding structure that is not supported until PHP version 5.5 and above. Section 1 below will illustrate said segments and how I overcame this.

---

So why were the errors not showing? (1)

The reason no errors were being displayed or logged in the magento logs was simple.

When the file(s) containing the incompatible segments of code is/are parsed, it will attempt to compile the code. But, when it reaches the incompatible segment it won't understand it and how to process this. Thus, causing a fatal error to be thrown, and in return caused the 500 internal server error.

As stated by interServer:

"The 500 Internal Server Error is the general catch all error when the server throws an exception. ... Simply, the 500 Internal Server Error is a general http status code that means something has gone wrong on the website's server, but the server could not be more specific on what that exact problem is."

This then prevented anything to be logged in magento.

As stated by media temple here:

...With any error message, particularly one as broad as the 500 Internal Server Error, you will first want to check any Apache and PHP error logs for your server. These logs can provide valuable context related to any code failures or other potential causes of a site failure.

How did I overcome this? (2)

As we are all aware, the 1.9.4.2 is a minor update from 1.9.4.1. Where there are some small bug fixes and enhancements. I.e. Escaping HTML and introducing a new mailiciousFilter(). No drastic changes, so this made me ask myself What possibly could have changed that caused this?

From here I formulated a simple plan of action:

1. Using the fantastic tool DiffMerge, I compared two fresh untouched versions of Magento 1.9.4.2 and 1.9.4.1;

2. Then I traversed the list of changes, seeing what was exactly changed in the update. And, sequentially applying and testing each change. Whereby, I Backtracked until the culprit change was identified and scope for possible causes was made smaller;

   Please Note: No changes were made on Production site at this point, and as per industry standard done in a like for like staging site.

From here, I was left with a very small scope for the cause. Namely, one perpetrating module: the AuthoriseNet Module, which as stated above, I do not use. But, it would still be parsed/compiled in magento when checking-out.

Analysing the changes in the module I was able to pinpoint that the following files:

• ../app/code/core/Mage/Authorizenet/Model/Directpost.php
• ../app/code/core/Mage/Authorizenet/Model/Directpost/Request.php
• ../app/code/core/Mage/Authorizenet/Model/Directpost/Response.php

All have one commonality, where they are passing the return of a function into the empty() function. For example,

`$hashConfigKey = !empty($response->getData('x_SHA2_Hash')) ? 'signature_key' : 'trans_md5';`

This duly causing a parse error, since as stated above in the question update and on the php official documentation:

Prior to PHP 5.5, empty() only supports variables; anything else will result in a parse error.

This left two options:

1. Update the server to PHP 5.5 or above;
2. And, amend the incompatible code.

Unfortunately, At this present moment in time Centos officially only supports 5.4. Thus, ruling out option 1. Yes! I am fully aware I could use another repository like the EPEL. But, unfortunately a decision has been made above myself to wait until Centos officially supports a newer version.

Luckily, magento is highly customisable and lends itself to overrides without even needing to create our own module.

Please Note! Never make changes to the core code. Instead make a local override and make changes there. Deepak Mishra (2014) has written a fantastic guide here, where he explains the simplest method to override core files in magento.

Following suite, I made a local override for the three afore bulleted files. And, amended them as guided by Magentary(2019):

--- app/code/core/Mage/Authorizenet/Model/Directpost.php
+++ app/code/local/Mage/Authorizenet/Model/Directpost.php
@@ -389,7 +389,8 @@
     public function validateResponse()
     {
         $response = $this->getResponse();
-        $hashConfigKey = !empty($response->getData('x_SHA2_Hash')) ? 'signature_key' : 'trans_md5';
+       $response_getData_hash = $response->getData('x_SHA2_Hash');
+        $hashConfigKey = !empty($response_getData_hash) ? 'signature_key' : 'trans_md5';

         //hash check
         if (!$this->getConfigData($hashConfigKey)
--- app/code/core/Mage/Authorizenet/Model/Directpost/Request.php
+++ app/code/local/Mage/Authorizenet/Model/Directpost/Request.php
@@ -187,7 +187,8 @@
     {
         $fpTimestamp = time();

-        if (!empty($this->_getSignatureKey())) {
+       $this_getSignatureKey = $this->_getSignatureKey();
+        if (!empty($this_getSignatureKey)) {
             $hash = $this->_generateSha2RequestSign(
                 $this->getXLogin(),
                 $this->_getSignatureKey(),
--- app/code/core/Mage/Authorizenet/Model/Directpost/Response.php
+++ app/code/local/Mage/Authorizenet/Model/Directpost/Response.php
@@ -56,14 +56,17 @@
      */
     public function isValidHash($storedHash, $merchantApiLogin)
     {
-        if (empty($this->getData('x_amount'))) {
+       $this_getData_x_amount = $this->getData('x_amount');
+        if (empty($this_getData_x_amount)) {
             $this->setData('x_amount', '0.00');
         }

-        if (!empty($this->getData('x_SHA2_Hash'))) {
+       $this_getData_x_SHA2_Hash = $this->getData('x_SHA2_Hash');
+       $this_getData_x_MD5_Hash = $this->getData('x_MD5_Hash');
+        if (!empty($this_getData_x_SHA2_Hash)) {
             $hash = $this->generateSha2Hash($storedHash);
             return $hash == $this->getData('x_SHA2_Hash');
-        } elseif (!empty($this->getData('x_MD5_Hash'))) {
+        } elseif (!empty($this_getData_x_MD5_Hash)) {
             $hash = $this->generateHash($storedHash, $merchantApiLogin, $this->getXAmount(), $this->getXTransId());
             return $hash == $this->getData('x_MD5_Hash');

Now, upon clearing cache and other prerequisites of changes, the checkout is working again with no errors whatsoever. This is because magento instead of reading the core files with the incompatible segments, it will read from our local override where we have corrected the segments to be compatible with PHP 5.4.