Undefined Index: SCRIPT_NAME

Which PHPA WordPress plugin on one of my client’s sites was filling up the error log with a PHP error “undefined index” for the server variable SCRIPT_NAME. The error persisted through a number of plugin updates. I found that I could work around it by editing the plugin’s code and substituting the server variable PHP_SELF instead of SCRIPT_NAME, but it was a hassle to modify the code for the plugin every time there was an update, and I wanted to find a permanent fix.

I verified that the SCRIPT_NAME server variable was working on the server itself by uploading this simple test script, which displays the values of a variety of commonly used PHP server variables:

<!DOCTYPE html>
  <html>
   <head>
    <meta charset="UTF-8">
    <title>Server Variable Test</title>
   </head>
  <body>
   <div id="wrapper">
    <div>
     <h4>Server Variables</h4>
    </div>
    <div>
      <?php $vals = array('REMOTE_ADDR', 'PHP_SELF', 'SERVER_NAME', 'PATH_INFO', 'DOCUMENT_ROOT', 'HTTP_HOST', 'HTTP_REFERER', 'SCRIPT_FILENAME', 'SCRIPT_NAME', 'REQUEST_URI', 'HTTP_USER_AGENT'); foreach ($vals as $val) { echo $val . ' = ' . $_SERVER[$val] . ' '; } ?>
    </div>
    <div>
     basename of SCRIPT_NAME = <?php echo basename($_SERVER['SCRIPT_NAME']); ?>
   </div>
  </div>
 </body>
</html>

I posted on the plugin’s support forum to see if anyone else was experiencing the same issue and had found a solution, but the developer was unable to reproduce the error and only one other user reported getting the same error message.

I had tried to reproduce the error by clicking around on the site, both on the front end and the back end, but at first, I couldn’t figure out how it was being triggered.

I had finally decided that the issue must be something to do with the server configuration itself, but I couldn’t find the cause, so I contacted our web host’s technical support. Naturally, they wanted to know how to reproduce the error. A closer look at the error log led to the key. I noticed that the errors were occurring regularly at three minutes past the hour. I knew the site was using a real cron job to run wp-cron.php instead of user activity, and the cron job was scheduled to run–you guessed it–at three minutes past the hour.

The Culprit

I ran the cron job from the command line and was able to reliably reproduce the error, and I passed that along to the technical support technician. He discovered that it was the path to PHP I was using in the cron job that was causing the problem.

The cron job was originally set up as follows:

/usr/bin/php -q /home/accountname/public_html/wp-cron.php

 

The cron job–and many others on the server set up with the same path to PHP–were running, but the correct path should have been:

/usr/local/bin/php -q /home/accountname/public_html/wp-cron.php

Once the path for the cron statement was corrected, the server variable SCRIPT_NAME was available, and the error was no longer generated.

I can’t explain why PHP_SELF was available with the incorrect path name to PHP and SCRIPT_NAME was not, but it certainly threw me off.

I found plenty of articles reporting issues with SCRIPT_NAME  on NGINX servers when I searched the web, but this issue occurred on a Linux server. I didn’t find a solution in all my searching, so I thought I would post this for others who might run across the same issue.

With command line access, you can find the correct path to PHP on your Linux server using the command:

which php

The Fix

The fix is to make sure you’re using the correct path in your cron statements.