PHP errors

murphaph

Hi All,
Reading through my PHP/SQL book I've encountered a problem with one of the examples. Here's the code I'm running (called example_9_7.php):

<?php
 
  include('db_login.php');
  require_once('DB.php');
 
  $connection = DB::connect("mysql://$db_username:$db_password@$db_host/$db_database");
 
  if (DB::isError($connection)){
	die("Could not connect to the database: <br />".DB::errorMessage($connection));
  }
 
  $query = "SELECT * FROM `books` NATURAL JOIN `authors`";
  $result = $connection->query($query);
 
  if (DB::isError($result)){
	die("Could not query the database:<br />".$query." ".DB::errorMessage($result));
  }
 
  echo('<table border="1">');
  echo '<tr><th>Title</th><th>Author</th><th>Pages</th></tr>';
 
  while ($result_row = $result->fetchRow()) {
	echo "<tr><td>";
	echo $result_row[1] . '</td><td>';
	echo $result_row[4] . '</td><td>';
	echo $result_row[2] . '</td></tr>';
  }
 
  echo("</table>");
  $connection->disconnect();
 
  ?>

and here's the errors (warnings really I suppose):

Strict Standards: Non-static method DB::connect() should not be called statically in C:\server\www\myserver.dev\public_html\example_9_7.php on line 6

Strict Standards: Non-static method DB::parseDSN() should not be called statically in C:\server\php\PEAR\pear\DB.php on line 520

Strict Standards: Non-static method DB::isError() should not be called statically in C:\server\php\PEAR\pear\DB.php on line 557

Strict Standards: Non-static method DB::isError() should not be called statically in C:\server\www\myserver.dev\public_html\example_9_7.php on line 8

Strict Standards: Non-static method DB::isManip() should not be called statically, assuming $this from incompatible context in C:\server\php\PEAR\pear\DB\common.php on line 2195

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in C:\server\php\PEAR\pear\DB\common.php on line 1217

Strict Standards: Non-static method DB::isError() should not be called statically in C:\server\www\myserver.dev\public_html\example_9_7.php on line 15

The book is (again) a bit vague. The warnings say to me "hey, you need to create an instance here and then use object->function() to manipulate me" but only the first and last errors are coming directly from my code, the rest are deep inside the pear DB package as it calls things itself. Any ideas on how to get rid of these errors properly?

Thx.

billymitchell

http://stackoverflow.com/questions/1248952/php-5-disable-strict-standards-error

murphaph

Thanks Billy, is this a normal thing to have to do? (to hide these errors I mean).

Where would I include that error reporting function in my code? (I tried just inside the php start tag but didn't work, still got the errors).

seamus

^^
That's not how you fix it properly.

I'm always stunned when someone's answer to fixing PHP warnings is "Switch off error reporting".

The reference in the warnings to a "static" call are talking about the way that you're calling the connect() function (for example).

In OOP, a "static" class is basically a function library. You don't use it to create multiple objects - it's basically one single global object which exists across all programs and provides functionality to those programs.

They're used in cases where the details and the functionality of those classes never wavers and therefore do not need to be manipulated. Java provides a "Math" class which provides access to standard mathematical values and functions. You would never instantiate a "Math" object because you will never be changing the value of PI or changing how you calculate the product of two numbers.

It's hard to explain until you use it really.

In this case you're trying to use the "DB" class as if it were a static class providing basic functions. A "DB" class wouldn't be static though because you would change the parameters of that class.

So what you need to do is create a DB "object" at the start of the script, and then you can work with that object specifically.

That is:

$connection = new DB();

$connection->connect("mysql://$db_username:$db_password@$db_host/$db_database");

Anywhere you're using "DB::" instead use "$connection->", so "DB::isError($connection)" becomes "$connection->isError()" and so forth.

billymitchell

Sorry OP, I should have stated that it wont fix your error messages but will only make them disappear. By the sounds of things the OP is only just starting out in programming, so just to keep him tipping along, I kind of gave him a cheat instead of a solution.
What Seamus said is probably the correct thing to do, but if you just want to make stuff work without getting too bogged down on the finer points of programming, stick with me

Anyhow, have you got it working?

murphaph

seamus wrote: »

^^
That's not how you fix it properly.

I'm always stunned when someone's answer to fixing PHP warnings is "Switch off error reporting".

The reference in the warnings to a "static" call are talking about the way that you're calling the connect() function (for example).

In OOP, a "static" class is basically a function library. You don't use it to create multiple objects - it's basically one single global object which exists across all programs and provides functionality to those programs.

They're used in cases where the details and the functionality of those classes never wavers and therefore do not need to be manipulated. Java provides a "Math" class which provides access to standard mathematical values and functions. You would never instantiate a "Math" object because you will never be changing the value of PI or changing how you calculate the product of two numbers.

It's hard to explain until you use it really.

In this case you're trying to use the "DB" class as if it were a static class providing basic functions. A "DB" class wouldn't be static though because you would change the parameters of that class.

So what you need to do is create a DB "object" at the start of the script, and then you can work with that object specifically.

That is:

$connection = new DB();

$connection->connect("mysql://$db_username:$db_password@$db_host/$db_database");

Anywhere you're using "DB::" instead use "$connection->", so "DB::isError($connection)" becomes "$connection->isError()" and so forth.

Cheers Seamus, I like to fix rather than hide as well.

I think the book I'm reading may not be the best tbh...here's what it says:

The DB.php file defines a class of type DB. Refer to Chapter 5 for more information on working with classes and objects. We'll principally be calling the methods in the class. The DB class has a connect method, which we'll use instead of our old connect function mysql_connect. The double colons (::) indicate that we're calling that function from the class in line 4:

...which seems to imply to me that the author intentionally called the DB class connect method statically. Is the author simply wrong here?

even if I create a DB object and manipulate it's functions (rather than statically), surely I'll still get the errors popping up from deep inside the DB package, which appears also to be calling methods statically when they should be instantiating instances of the class first.

murphaph

Billy, yeah, the cheat works alright, but I'm uneasy with it of course...would like to have it working cleanly if at all possible. Yes, I'm new to php but I understand the principles of OOP. I learned Java before ever seeing php. In Java this just wouldn't be allowed...a static function is a static function etc. There would be no warnings, just compile time errors.

seamus

murphaph wrote: »

...which seems to imply to me that the author intentionally called the DB class connect method statically. Is the author simply wrong here?

even if I create a DB object and manipulate it's functions (rather than statically), surely I'll still get the errors popping up from deep inside the DB package, which appears also to be calling methods statically when they should be instantiating instances of the class first.

"Wrong" is a harsh word to use.

The beauty of PHP is it's loose typing and its general willingness to attempt to do almost anything without killing your script. It lets you code quickly. But that can also lead to unintended conequences when you start doing cross-context stuff like this and pointers are being moved about. As you say a Java compiler would beat you about the head with a piece of wood for doing this.

So I wouldn't say that it's "wrong", but it's risky programming, especially if you're looking to deploy the application publically.

It does appear as though the class you're using has been somewhat shoddily written. Functions within a class should always use the $this object when calling methods in that class which makes changes to the object itself.

It would be a good learning experience to fix both your warnings and the author's warnings

billymitchell

Sorry murph, I assumed that you were new to development in general. If you already have done coding, then follow what Seamus said, it is the more correct thing to do.
I just started doing a bit of php a year or two ago, and starting out I just wanted things to work rather than being worried about them being do "correctly". So I only worried about warnings and errors at the start, anything after that I felt was an unnecessary overhead for what I wanted to accomplish.

Anyway, glad you got it working.

murphaph

Thanks guys, I'm going to have a bash at rewriting the whole lot to eliminate these errors then....but not just now lol.

Appreciate the pointers, genuinely.:)

Edit: Billy, I am still new to programming in a professional capacity, I am an electronic engineer by profession but recently got a job as a junior programmer and it's all PHP/SQL stuff I need to learn.

Evil Phil

You could also email the author(s) and ask them about the issues, they may throw more light on the subject or if there is an error in their book they'll be able to update for the next edition. Is there an errata page for the book on the web somewhere?

murphaph

Ok, so by creating instances etc. in my own code, the errors have been reduced to

Strict Standards: Non-static method DB::isManip() should not be called statically, assuming $this from incompatible context in C:\server\php\PEAR\pear\DB\common.php on line 2195

Strict Standards: Non-static method DB::isError() should not be called statically, assuming $this from incompatible context in C:\server\php\PEAR\pear\DB\common.php on line 1217

...which are deep inside the DB package from PEAR. Can I ask, what would the pro PHP developers normally do here? hide and log the remaining errors or go and try to fix the other code? I understand it would be a good learning experience, but in reality when people us pear packages and stuff like this happens, what do you do? Turn error reporting down a notch?

murphaph

Evil Phil wrote: »

You could also email the author(s) and ask them about the issues, they may throw more light on the subject or if there is an error in their book they'll be able to update for the next edition. Is there an errata page for the book on the web somewhere?

Oh God:
Reviews for this book

Lol, I'm glad I didn't buy it in hardcopy format (it's on my Safari bookshelf). I'll muddle through with it for a while yet, the errors are actually good for learning I find.

jmcc

PEAR DB is installed properly? Some professional PHP programmers tail the error log in a separate window when developing and curse when things go wrong. But then comes the job of fixing the problem and that's what differentiates the pro from the amateur - the pro has to fix the problem. I don't use PHP on Windows but I remember from default installations of PHP/Apache on Linux boxes that sometimes PEAR wasn't installed and on others various essential things like DB may not have been installed. This caused scripts accessing databases to fail.

Regards...jmcc

murphaph

cheers jmcc, DB wasn't installed on my pear installation. Had to use the installer to fetch and install it, which it did without errors.

jmcc

murphaph wrote: »

cheers jmcc, DB wasn't installed on my pear installation. Had to use the installer to fetch and install it, which it did without errors.

At first glance, the example code above should work now - or at least give a different set of errors.

Regards...jmcc

murphaph

<html>
<head>
<title>Using Default Checkbox Values</title>
</head>
<body>
<?php
[B]$food = $_GET["food"];[/B]
if (!empty($food)){
echo "The foods selected are: <strong>";
foreach($food as $foodstuff){
echo '<br />'.$foodstuff;
}
echo "</strong>.";
}
else {
echo ('
<form action="'.$_SERVER["PHP_SELF"].'" method="GET">
<fieldset>
<label>
Italian
<input type="checkbox" name="food[]" value="Italian" />
</label>
<label>
Mexican
<input type="checkbox" name="food[]" value="Mexican" />
</label>
<label>
Chinese
<input type="checkbox" name="food[]" value="Chinese" checked="checked" />
</label>
</fieldset>
<input type="submit" value="Go!" />');
}
?>
</body>
</html>

(my bold on line 7)

Error is:

Notice: Undefined index: food in C:\server\www\myserver.dev\public_html\example_10_5.php on line 7

I don't really see how to fix this, any ideas? Thx.

seamus

Line 7 is this guy:

[PHP]$food = $_GET["food"];[/PHP]

$_GET is a special global variable which contains all variables passed to the script by the browser in the GET request. When you see a web page, such as this one, you may see the name of the page, e.g. http://www.somesite.com/somepage.php, followed by a question mark and then some data. These are the GET variables. They are set up as varname=value and separated by ampersands.

So if for example we have
http://www.somesite.com/somepage.php?varA=valueA&varB=valueB

This passes two variables to the page, varA and varB with two values "valueA" and "valueB" respectively.

Within your PHP script then, these can be accessed through the $_GET variable as items. The $_GET variable is an associate array.

So if I say
[PHP]echo $_GET;[/PHP]

Then the script will output "valueA".

If varA has not been passed to the script, i.e. you access http://www.somesite.com/somepage.php without any variables, then the above echo command will output a blank line and you will see a warning.

In the case of the above, the script is trying to access a GET variable "food" without actually checking if this variable exists and has been passed to the script.

Obviously you should always check to see if a variable has been defined before you try to use it.

The most simple way is a standard if block, i.e.

[PHP]if(isset($_GET))
$food = $_GET;
else
$food = "";[/PHP]

But that's long-winded and painful if you have 15 or 20 variables being passed in. A ternary operator will do the exact same as the above, but look much neater;
[PHP]$food = isset($_GET)? $_GET : "";[/PHP]
Afaik, PHP's ternary operator is identical to Java's, so it may be somewhat familiar to you.

murphaph

Top man Seamus, that's sorted it and thanks for the extra explanation .

How crap is this book though? All the examples in this section generate this error. Starting to p!ss me off...I just want to learn PHP after all! Anybody got any recommendations for books (esp O'Reilly books as I have a Safari subscription) that encompass PHP/mySQL?

jmcc

murphaph wrote: »

[code]<html>
<head>
<title>Using Default Checkbox Values</title>
</head>
<body>
<?php
$food = $_GET["food"];

Try it as
$food=$_GET;

and also change the " to ' on
$_SERVER

Edit: Just tried it on Linux/PHP5 and the code worked. There's a very slight possibility that Windows may be more restrictive about the use of ' and " or how it is using $_GET.


The ' and " might be used interchangeably in some languages but I think that PHP may handle them differently in that anything within the double quotes will get expanded (PHP should interpret and substitute any variables etc) whereas anything in single quotes will be considered exact.

I took a look through the reviews of that book on O'Reilly and Amazon and you might be better off getting another book to use as an introduction. Don't rely on this book for anything to do with MySQL. The "Programming PHP" book by Rasmus Lerdorf, Kevin Tatroe and Peter MacIntyre (Also an O'Reilly book) would probably be a lot better as an introduction as it gets up to speed rapidly and has a good introduction to the language in the first section of the book. The "PHP Cookbook" is interesting when PHP begins to make sense.

Most of the stuff in PHP is really obvious as it is built on C and, to an extent, on Java. Pear (pear.php.net) saves people from reinventing the wheel but where a package is used in a script without explanation or reference it can cause problems (as it did here).

Regards...jmcc