MySQL4 or Apache1 causing problems with PHP5?

[CathInfo]

I am running phpShop 0.6.1 (an older version, yes, but it works) on a Hostgator server that hasn't been upgraded yet.

It's currently running on PHP4/MySQL4/Apache1.

To test it on PHP5, I installed XAMPP (highly recommended, BTW) which setup is as follows: PHP5.25/MySQL5/Apache2.2

On this setup -- on a Windows machine, no less -- it works great! I just had to turn register_globals and register_long_arrays on.

Anyhow, if I enable PHP5 on my Hostgator account, it succeeds (which I can prove by using the php_info() command), but phpShop doesn't work.
Moreover, I am succeessful in turning on the two switches I mentioned, which are important for the operation of phpShop. I verified this by looking at php_info() again.

So I have proven that phpShop 0.6.1 works with PHP5 -- it obviously isn't a PHP5 issue. That is, there is nothing to patch/fix/whatever. But for some reason, the site won't navigate between pages. Whatever page I go to, it keeps me on the "homepage" -- which is classic behavior for register_globals being turned off, or the PHP.INI file being absent on the server -- which results in the same (at least those two things caused this "persistent homepage" symptom in the past).

So now I'm left wondering whether MySQL4 is causing the problem, a combination of PHP5/MySQL4, or Apache1. If it's MySQL4, I shouldn't have any problems because when my server gets upgraded, it will have MySQL5. But what if Apache1 is the problem? How could it be, and what could I test/look into to learn more?

"Google" (the aggregate of webmaster knowledge online) seems to think that there are few differences between Apache1 and 2. Mostly performance improvements, etc. But maybe I missed an important message somewhere.

I would be grateful for any help.

Sincerely,

Matthew

[Goddess Dix]

register globals turned on via php.ini has to be turned on in each directory where the php scripts reside individually. so while it might be on in your root, if you navigate to another directory, you need another php.ini in that directory, or it is off.

is there a newer version of the script that doesn't require register globals? in additon to making your life easier here--always a good goal--register globals is off by default beause of security problems; running older versions of scripts often greatly increase your security risk as well. while i'm not familiar with this particular script, many exploits rely on people running older scripts and you're much more likely to get burned that way.

good luck.

[CathInfo]

I placed PHP.ini in all the subdirectories -- but the main file is in the root (index.php) and all other *.ihtml files are outside the file structure (they are outside the public_html directory -- not accessible from the web) The program uses the include statement or some equivalent.

Anyhow, I tried it anyhow, and it didn't work. When I run php_info() it shows that register_globals is on.

I am using phpShop 0.6.1 which isn't really being developed anymore. They have a later version, but it's not a simple upgrade. They are trying to make templates out of all the pages -- right now the HTML and PHP are mixed together. Like I said, not a simple upgrade.

And in fact I heard that 0.6.1 works with PHP5, whereas 0.8.1 doesn't.

I don't have time to set up Joomla/Virtuemart or OScommerce at the moment -- my home business is only a side job for me, and I only have a few hours a week to work on it.

As I said in my original post -- PHP5 can't be the problem, because if I upload the exact same php.ini, .htacesss, and file structure to my testbed, it works 100%. So it has to be MySQL4 or Apache1 -- it's a question of science and logic.

Matthew

[whatrevolution]

Neither assumption (Apache or MySQL) is safe. If it were a MySQL error, you'd likely have PHP barfing at you. If it were Apache, you'd likely have an unmistakeable error.

Your symptoms are a soft error that isn't halting any of the code's runtime. This could occur when, such as with register_globals turned off, code is expecting a variable that wasn't instantiated by the GET request (the URL), but the code is correct enough to at least check isset($variable) before just USING it... since no URL parameters to index.php means serve the homepage.

Without a real Apache error, the only Apache issue that comes to my mind is a RewriteRule killing the URL variables... but that'd happen in XAMMP, too, if you're testing an exact copy of the tree.

Without a MySQL error, it doesn't make sense for some MySQL query to be compatible in 4 & 5, but not return data in one or the other. If it didn't return data, it's probably because it's incompatible in one or the other, and THAT typically throws an exception that kills runtime in one of a variety of ways. A MySQL guru would quote me an exception to that statement, but I'm speaking generically.

You need debug information. You won't have much luck tracking this if you're only looking at the page it's erroneously serving you.

[CathInfo]

I'll try anything --

How do I go about looking at debug information? Is Firefox's DOM inspector enough? Or do I need to look at server logs?

Matthew

[CathInfo]

Here is some code I'd like to look at in more detail:

  
//**************************************************
// TRANSLATE FROM SEARCH-ENGINE FRIENDLY URLS
//**************************************************
  $HTTP_TEMP_PATH_VARS = explode("/",$PATH_INFO);
  array_shift($HTTP_TEMP_PATH_VARS);
  reset($HTTP_TEMP_PATH_VARS);
  $HTTP_PATH_VARS = array();
  while( list($index,$key) = each($HTTP_TEMP_PATH_VARS) ) {
    list($index,$val) =  each($HTTP_TEMP_PATH_VARS);
    $val = urldecode($val);
    $HTTP_PATH_VARS[$key] = $val;
    $HTTP_GET_VARS[$key] = $val;
    $$key = $val;
  }
  $page=strtr($page, ":", "/");

[CathInfo]

I did determine that $PATH_INFO is null in PHP5, whereas it contains the destination page (everything after "index.php/") in PHP4!

$PATH_INFO is not a program variable -- it's something more than that (I'm not sure exactly what it is)

Every page is formatted this way:

http://www.chantcd.com/index.php/page/shop:lyrics/

/page/shop:lyrics/ is contained in $PATH_INFO in PHP4 -- it's blank in PHP5

[whatrevolution]

Originally Posted by CathInfo

I did determine that $PATH_INFO is null in PHP5

$PATH_INFO is a stupid deprecated superduperultimatemagic hardcore </sarcasm> variable... Supposed to use $_SERVER['PATH_INFO'] now.

Two options, as always. 1) Recode, 2) Upgrade.

Sorry. :\

[CathInfo]

Since $PATH_INFO is bitten into apparently only once -- I might just have to change it there, and it should work!

I was wondering what the new name was -- thanks for your help!

Matthew

[whatrevolution]

Originally Posted by CathInfo

I might just have to change it there, and it should work!

Perhaps. It doesn't bode well for the state of the rest of the code, though. Roll the dice, if you must~

[CathInfo]

Well, I made the change and tested it, and it seems to work fine throughout the site EXCEPT ONE IMPORTANT THING...sessions.

Is there a well-known change of design in the "session" between PHP4 and PHP5? Right now, the session doesn't seem to exist. Here is an excerpt from the code:

<?php
/*
 * The ps_session class for PHP4
 *
 * Copyright (c) Edikon Corporation.  All rights reserved.
 * Distributed under the phpShop Public License (pSPL) Version 1.0.
 *
 * $Id: ps_session_4.inc,v 1.5 2000/09/13 16:34:38 pfmartin Exp $
 *
 */



class ps_session {
  var $classname = "ps_session";
  var $table_name = "sessions";
  var $serial_spacer = "|";
  var $firstcall;

  // Public
  function ps_session($newname = "ps_session", $forcenew=0) {
    session_start();
  }


  // Public
  // Reference a global variable into the session
  function register($var) {
    session_register("$var");
  }

  // Public
  // unreference a global variable from the session
  function unregister($var) {
    session_unregister($var);
  }

  // Public
  // clear the session
  function destroy() {
    session_destroy();
  }

  // Public
  // save all registered variables.  Should be called at end of page
  function save() {
    return True;
  }


  //makes a URL search engine friendly
  function seurl($url){
    list($domain,$query)=explode("?",$url);
    $query=strtr($query,"/",":");
    $query=strtr($query,"&","/");
    $query=strtr($query,"=","/");
    return $domain."/".$query;
  }

  // Need these for backwards phplib compatibility
  function url($text) {
    global $QUERY_STRING;
    global $HTTP_COOKIE_VARS;
    global $HTTP_GET_VARS;
    global $HTTP_POST_VARS;

    if (empty($HTTP_COOKIE_VARS[$this->name])) {
      // Check for argument delimiter
      if (strpos($text, "?")) {
         $delim = "&";
      }
      else {
         $delim = "?";
      }
      //return $text . $delim . SID;
      return $this->seurl($text . $delim);
    }
    else
      return $this->seurl($text);
  }

  function purl($text) {
    global $QUERY_STRING;
    global $HTTP_GET_VARS;
    global $HTTP_POST_VARS;

    global $HTTP_COOKIE_VARS;

    if (empty($HTTP_COOKIE_VARS[$this->name])) {

        // Check for argument delimiter
      if (strpos($text, "?")) {
               $delim = "&";
        }
        else {
               $delim = "?";
        }
        //echo $text . $delim . SID;
        echo $this->seurl($text . $delim);
        return 1;
     }
     else {
        echo $this->seurl($text);
        return 1;
     }

  }

  function hidden_session() {
    echo "<INPUT TYPE=HIDDEN NAME=" . session_name() . " VALUE=" . session_id() . ">";
  }

  function cleanup() {
    return True;
  }

} // end of class session
?>

[CathInfo]

I compared the SESSION section of PHP 5.2.2 and the current 4.4.4, and found one main difference:

PHP4: session.save_path = "/tmp"
PHP5: session.save_path = "none" (or something similar)

So I added the line
session.save_path = "/tmp"
to php.ini, and uploaded it to every directory in my website.

The problem persists, however.

Oddly, if I add items to my cart, the cart page it redirects me to DOES have all the items I've added -- in other words, it's the cart I'd expect to see. But if I click on the link which brings up the cart, it shows an empty cart. The latter uses the $SERVER['PATH_INFO'] derived variable (the URL parameters). That is, it has a bunch of stuff after the main page "index.php"

but if I see the cart filled with items, the URL address bar always has nothing after "index.php" -- as if everything else is behind the scenes or hidden.

I'll keep looking into it.

Matthew

[Goddess Dix]

don't have any experience running above the root. have you checked the support forums or whatever suport option they have for your script? you can't be the first person to come across this.

[codesight]

the session_register method is deprecated in favor of just setting your session variables with $_SESSION

As an example, instead of using

session_register("$var");

you would use

$_SESSION["$var"] = null;

give that a whirl, it could get ugly trying to replace all deprecated code, but sometimes, when OO isn't used too much, you could be fine with removing the smaller deprecated items

[CathInfo]

I'm starting to think that "sessions handling" isn't causing the problem.

I did a grep search, and discovered that only "vendor_id" is registered in this way currently. I would have guessed a lot more variables were registered...but apparently not.

When I made the change from session_register("$vendor_id"); to $SESSION['vendor_id'] (but didn't change all the instances of $vendor_id in the code), the behavior was as expected. But all I had to do was change $vendor_id to "1" everywhere it was used, and everything works. (I don't use the multiple vendor feature -- talk about an overkill feature for most online stores).

But the shopping cart still shows up empty -- UNLESS I get there after adding a new item, then everything shows up again. Very strange. I don't know where to begin in figuring out why.