upgrading from 4.0.4 to 4.3.7 broke my code! Please help!

bobII

The following code was used to display the contents of a DB. When a user entered in a value in the form, the results.php page (see below) would basically display the results.

Here is the code for the form:
<html>
<head>
<title>Product Search</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>
<STYLE>A {
TEXT-DECORATION: none
}
A:hover {
COLOR: #ff3333; TEXT-DECORATION: underline
}
</STYLE><LINK
href="styles.css" type=text/css rel=stylesheet>

<body ONLOAD="document.price_search.searchterm.focus();" bgcolor="#ececec" leftmargin=0 topmargin=0>
<table width="375" border="1" align="left" cellpadding="2" cellspacing="0" bordercolor="#999999">
<tr>
<td width="343" height="20" bgcolor="#CCCCCC"><font color="#FFFFFF"><font color="#FFFFFF"><img src="images/product_search.gif" width="143" height="25"></font></font></td>
</tr>
<tr>
<td height="85" bgcolor="#FFFFFF">
<table width="100%" height="100%" border="0" cellpadding="2" cellspacing="0">
<tr>
<td><font color="#FFFFFF"><font color="#FFFFFF"><strong></strong></font></font>
<form name="price_search"action="results.php" method="post">
<font size="1" face="Verdana, Arial, Helvetica, sans-serif"><br>
<input name="searchtype" type="hidden" value="prodnumber">

<br>
<br>
Enter Product Number:<br>
<input type="text" getFocus="1"class="submit" name="searchterm" >
</font><font color="#FFFFFF"><font color="#FFFFFF"><font color="#333333" size="1" face="Verdana, Arial, Helvetica, sans-serif"><em>(I.E.
4014-11 or 4014)</em></font></font></font><br>
<br><input name="submit" type="submit" class="submit" value="Search" tabindex="1" align="absmiddle">
</form>
<font color="#FFFFFF"><font color="#333333"> </font> </font></td>
</tr>
</table></td>
</tr>
</table>
</body>
</html>

Here is the code for the results: (results.php)

<?
if ( !$searchterm )
{
echo "You have not entered search details. Please go back and try again.";

 exit;

}

$searchterm = addslashes($searchterm);

@ $db = mysql_connect("localhost", "dbname", "");

if (!$db)
{
echo "Error: Could not connect to database. Please try again later.";
exit;
}
mysql_select_db("dbname");
#$query = "SELECT FROM prices WHERE ".$searchterm." like '%".searchtype."%'";
$query = "SELECT FROM prices WHERE ".$searchtype." like '%".$searchterm."%'";

$result = mysql_query($query);
$num_results = mysql_num_rows($result);

echo "<p><br><i>Number of products found: ".$num_results."</i></p>";

$first_rec = "y";

$prod_comp = "";

$cnt = "1";
for ($i=0; $i <$num_results; $i++)
{
$row = mysql_fetch_array($result);
$a_prod = stripslashes($row["prodnumber"]);
$a_price = stripslashes($row["price"]);
$a_um = stripslashes($row["um"]);

 if ( $first_rec == 'y' )
{
   $first_rec = 'n';
   $prod_comp = $a_prod;
   echo "<p><strong>".($cnt).". Product Number: ";
   #echo "<p><strong>".($i+1).". Product Number: ";
   echo $a_prod;
}

 if ( $prod_comp != $a_prod )
{
   $cnt = $cnt+1;
   $prod_comp = $a_prod;
   echo "<p><strong>".($cnt).". Product Number: ";
   echo $a_prod;
}

echo "</strong><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;price: ";
echo $a_price; 
echo "<i>&nbsp;";
echo $a_um;
echo "</i>";

}
?>
</font><font color="#333333"> </font> </font></td>
</tr>
<tr>
<td> </td>
</tr>
<tr>
<td><a href="javascript: history.go(-1)">Back to Search Page</a><br>
<script language="Javascript1.2">
<!--

var message = "Print this Page";

function printpage() {
window.print();

}

document.write("<form><input class=submit type=button "
+"value=\""+message+"\" onClick=\"printpage()\"></form>");

//-->
</script>

Now I'm getting an error:

Notice: Undefined variable: searchterm in C:\InetPub\wwwroot\newsite\results.php on line 20

Notice: Undefined variable: searchtype in C:\InetPub\wwwroot\newsite\results.php on line 43

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in C:\InetPub\wwwroot\newsite\results.php on line 46

I'm guessing that something drastically has changed between 4.0.4 and 4.3.7... Any ideas what is wrong with my code?

laserlight

Many things have drastically changed since PHP 4.0.4

For one thing, read this forum's FAQ on register_globals.

rachel2004

Originally posted by bobII
I'm guessing that something drastically has changed between 4.0.4 and 4.3.7... Any ideas what is wrong with my code?

I could probably help you better if you use the PHP buttons you see when you submit. Then everything will be color-coded for easier readability.

I don't wish to spend too much time on one thread if I can solve something quickly, so please post with the little helper buttons that this forum provides.

There are a lot of thigs that changed between 4.0.x and the 4.3.7 versions of PHP as laserlight already said, and I can't spot the weakpoints in your code quickly without the color-coding.

mhalloran

It's the globals thing. Do a search for "PHP globals" and you'll be flooded with information because it was a big change.

Add these lines to the begining of your script:

error_reporting  (E_ERROR | E_WARNING | E_PARSE);
$searchstring=$_POST["searchtype"];
$searchterm=$_POST["searchterm"];

You may not need the error reporting line but it looks like it's set high on your server.

You can turn register globals on by going to the php.ini file and changing the line:
register_globals Off
to
register_globals On

If you don't do that, you'll have to change all variables that retrieve their content from outside the page to things like
$POST[""], $GET[""], $SESSION[""] and $SERVER[""]. It's better coding and more secure but it takes more time.

It's not typical to declare them at the top of the page like I just did in the code block but that's a quick fix.

mmilano

open your php.ini file
look for the line register_globals Off
make it: register_globals On
look for the line that starts with 'error_reporting'
make it: error_reporting = E_ALL & ~E_NOTICE
```
register_globals On
error_reporting  =  E_ALL & ~E_NOTICE
```
now restart apache, iis, or whatever you use.

TheDefender

If you don't do that, you'll have to change all variables that retrieve their content from outside the page to things like
$POST[""], $GET[""], $SESSION[""] and $SERVER[""]. It's better coding and more secure but it takes more time.

This isn't entirely true... You can use the extract() function inserted above any references to any variables, and that will extract the individual variables out of the GET, POST and SESSION arrays by name.

extract($_GET);
extract($_POST);
extract($_SESSION);

Of course this can cause problems if you are POSTING a value into a variable and using SESSIONS to store a different value into a variable with the same name. I don't run into this type of issue very often if at all, as I generally use sessions for admin functions, and I name my variables something like $admin_username, $admin_email, etc... and I rarely ever use GET and POST methods simultaneously. Just some food for thought.

Also, if you don't have access to your PHP.ini (ie, offsite webhosting) or your webhost won't make that change to turn on Register Globals, then that's not even an option, so you will need to look at the other options. (extracting the variables, or using the $_POST['']; method.

mmilano

i think they started defaulting the error reporting to all and globals on since php 4.3 or something ..

this is obviously his problem.

if he wants his server to work like it used to, then he should follow my instructions instead of editing all his code.

TheDefender

Also, if you don't have access to your PHP.ini (ie, offsite webhosting) or your webhost won't make that change to turn on Register Globals, then that's not even an option, so you will need to look at the other options. (extracting the variables, or using the $_POST['']; method.

Nobody is saying your ideas won't work, and everybody knows this is the issue.

As I stated above, it may not be a viable solution (for the aforementioned reasons). Editing the code may be the necessary route, and until he confirms all of his options, we need to keep all of the options open. Afterall, all he said was the problems started after the PHP was upgraded. He didn't say who did the upgrading, or where the files are hosted.

mhalloran

I can't imagine a host switching globals off after having clients build and run their sites in a "globals on" environment. I understand why new clients may want globals on but they would be screwing their existing clients by forcing them all to put a lot of time/money into their sites.

I never heard of the extract function by the way... pretty cool.

TheDefender

You know, a lot of hosts kind of inadvertently did just that to their customers when they upgraded their PHP, and when all of the hoopla surrounding the why's were made known, a lot of hosts went with the old "We don't want to compromise security for everyone for the sake of a few".

The way I see it, it forces people to write a more secure code that works regardless of the setting... Yeah, it can mean a whole lotta work for people, but the way IDEs are written now, those kind of updates can be semi-automated and batched anyhow...

I personally use the extract() function quite a bit, because I hate writing out the entire $_POST['variablename']; thing, but I only use it with POST and SESSION, because it can open vulnerabilities with GET which was the reason for the whole change in the first place... But to each his own.

BuzzLY

Originally posted by mhalloran
If you don't do that, you'll have to change all variables that retrieve their content from outside the page to things like
$POST[""], $GET[""], $SESSION[""] and $SERVER[""]. It's better coding and more secure but it takes more time.

A quick and dirty way to do this, although not entirely secure, is as such:

foreach ($_POST as $key=>$value) {
  $$key = $value;
}
foreach ($_GET as $key=>$value) {
  $$key = $value;
}

I recommend this rather than setting register_globals = ON. You REALLY should do what you can to keep that setting OFF.

Weedpacket

Originally posted by BuzzLY
I recommend this rather than setting register_globals = ON. You REALLY should do what you can to keep that setting OFF.

And if you can code so that there are no errors when error reporting is set to E_ALL, even better.

Sure, you can extract whichever $_FOO[] arrays if you want, but the only up side is "not needing to change the code". Compare that with the security and performance downsides (and if the script is run on a server that has register_globals on, the performance drop doubles because it's basically having to do all that extraction twice - okay, it's only a small amount, but it's there.)

TheDefender

Hey Weed, it's a good temporary solution while rewriting the rest of the code ;-) Hey, did anybody notice that the original poster hasn't responded? LOL. So why are we having this discussion...

When I say I use it quite a bit, I don't mean I use it in my own code. I mean I use it as a temporary solution for clients in the process of rewriting their existing code. (and even to this day, I still get a lot of it) It's easy work that makes a quick buck... You know how it goes. "Add this code temporarily, and then rewrite the rest of your code per these guidelines. Now, if you don't mind, I will be collecting my consult fee, and be on my way."

I did do a performance test on my own machine locally, and it was insignificant, but I would imagine it may be more significant on a server across the globe on a 56K dialup perhaps...

bobII

Thanks everyone for all the help! As a quick fix, I turned register_globals = on and that fixed my problem! I'm going to work on rewriting the code in my scripts so I won't run into this problem again.

Thanks again! 😃