[RESOLVED] Lists

[cluelessPHP]

I'm working with lists and getting used to arrays ect. I have an ordered list however it's only returning 1. as the value of each list item (this might belong in database section not entirely sure)

<?php 

try{
           $db = new PDO("mysql:host=localhost;dbname=database", 'root', '');
           $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    }  catch(PDOException $e)
    {
            echo $e->getMessage();
            die();
    }

try
{
    function lists(PDO $db)
    {
        $select = $db->prepare("SELECT * FROM music ORDER BY sales DESC");
        $select->execute();
        $text = '';
        $list = array();
        while($row = $select->fetch(PDO::FETCH_ASSOC))
        {
            $text .="<ol>\n";  
            $text .="<li>{$row['artist']} " . "{$row['album']}" . " {$row['sales']}" . " {$row['genre']} </li>\n";        
            $text .= "</ol>\n";

        }
         return $text; 
    }
}
catch(Exception  $e)
{
     echo "Message" . $e->getMessage(); 
     die();
}

echo lists($db);

[Weedpacket]

First of all, you want the try{...}catch{...} to be inside the lists function. Where you have it now, you're only catching exceptions that are thrown when the function is created, not when it's called.

But the problem is that you're starting ([font=monospace]<ol>[/font]) and ending ([font=monospace]</ol>[/font]) a whole new ordered list for every single row. That's why they're all numbered "1." - they're all the first entries in their own individual lists.

[cluelessPHP]

<?php 

try{
           $db = new PDO("mysql:host=localhost;dbname=database", 'root', '');
           $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    }  catch(PDOException $e)
    {
            echo $e->getMessage();
            die();
    }


    function lists(PDO $db)
    {

    try
     {    
            $select = $db->prepare("SELECT * FROM music ORDER BY sales DESC");
            $select->execute();
            $text = '';
            $list = array();
            $text .="<ol>\n";  
            while($row = $select->fetch(PDO::FETCH_ASSOC))
            {              
                $text .="<li>{$row['artist']} " . "{$row['album']}" . " {$row['sales']}" . " {$row['genre']} </li>\n";                       
            }
            $text .= "</ol>\n";
            return $text; 
     }
    catch(Exception  $e)
     {
          echo "Message" . $e->getMessage(); 
          die();
      }
}


echo lists($db);

keep the parent(?) of the list outside the loop

[pbismad]

Unless a database error has meaning to your application and your application is responsible for handling it, such as for a value that causes a duplicate key/value error, and you want to tell the visitor a value they tried couldn't be used, you should not catch exceptions in your application code and you should not have code that unconditionally echos the raw database errors out on a page, as this gives hackers useful information when they deliberately trigger errors.

If you let php catch the exceptions, php will use its error_reporting, display_errors, and log_errors settings to control what happens with the actual error information. You can then eliminate those try/catch blocks and just by setting the display_errors and log_errors settings, you can switch from displaying errors, during learning, development, and testing, to logging errors, when on a live server.

[cluelessPHP]

pbismad;11063199 wrote:

Unless a database error has meaning to your application and your application is responsible for handling it, such as for a value that causes a duplicate key/value error, and you want to tell the visitor a value they tried couldn't be used

For duplicate keys ect. wouldn't that mean you haven't normalized the database to at least 3rd normal form? If I understand database integrity correctly using UNIQUE should prevent that no?

pbismad;11063199 wrote:

you should not catch exceptions in your application code and you should not have code that unconditionally echos the raw database errors out on a page, as this gives hackers useful information when they deliberately trigger errors.

So it would be like validation for lack of a better definition? In example:

if(empty($errors)) 
	{
		try
		{
			$success = ["message" => "Please check your Email address to activate your account"];	
			$database->query('INSERT INTO username (username_id, password ,activecode, joinedDate, eMail, active, img_name, img_path, img_type)
			VALUES
			(:username, :password,:activationCode, NOW(), :email, 0, :filename, :filepath, :filetype)');
			$database->bind(':username', $username);
			$database->bind(':email', $email);
			$database->bind(':password', password_hash($post['password'], PASSWORD_DEFAULT));
			$database->bind(':activationCode', $activationCode);
			$database->bind(':filename', $filename);
			$database->bind(':filepath', $filepath);
			$database->bind(':filetype', $filetype);
			$database->execute();
			$code = 'http://gotsocial.co.uk/gotsocial/active.php?activecode=' . $activationCode . '. 
                ';
			$to = $post['email'];
			$subject = 'GOT Social';
			$from = "[e-mail]";
			$result = mail($to, $subject, $code, "From: $from");
		}
		catch(Exception $e)
			{
				$errors[] = ["name" => "username", "error" => "Username or E-mail may already be registered"];
			}	

}	

pbismad;11063199 wrote:

If you let php catch the exceptions, php will use its error_reporting, display_errors, and log_errors settings to control what happens with the actual error information. You can then eliminate those try/catch blocks and just by setting the display_errors and log_errors settings, you can switch from displaying errors, during learning, development, and testing, to logging errors, when on a live server.

Something like this? (not sure I follow 100% in honesty)

error_reporting(-1); // reports all errors
ini_set("display_errors", "1"); // shows all errors
ini_set("log_errors", 1);
ini_set("error_log", "php-error.log");

[pbismad]

For duplicate keys ect. wouldn't that mean you haven't normalized the database to at least 3rd normal form? If I understand database integrity correctly using UNIQUE should prevent that no?

It would mean that you HAVE setup a UNIQUE constraint and attempting to insert/update a duplicate value resulted in a query error.

So it would be like validation for lack of a better definition?

Yes, actually, it's an application error. A value doesn't meet your application's requirements.

The code to handle it needs to test for the duplicate key/index error number (1062) so that it only operates on that particular error number and it needs to re-throw the exception for all other error numbers so that any main/php exception handler gets control.

If there is a duplicate index/key error, when multiple columns are defined as unique, the error occurs on the first column found with a duplicate value. You can parse the error message to get that column name or you can run a SELECT query (in the error handling logic) to find all column(s) that are being duplicated, then use this when building any user error message.

Something like this?

Yes, but the settings should be in a php.ini configuration file, so that you don't need to remember to set them, remove them, or change them when moving code from one environment to another and so that even php parse/syntax errors (in your main file) will get reported.

Error_reporting should always be set to either E_ALL or a -1. When learning, developing, or debugging code, display_errors should be ON. When on a publicly accessible server, display_errors should be OFF and log_errors should be ON.

As this pertains to exceptions, if you don't catch an exception in your code, php will. They will produce a fatal run-time uncaught exception error. If the error_reporting setting is set to report fatal run-time errors (which it will be with either the E_ALL or the -1 setting), php will attempt to report the error, which contains all the actual information about the error. Then, php will use the display_errors/log_errors settings to determine what happens with the reported error information.

[pbismad]

Continuation of the above - for your example code, the try/catch would only be around the execution of the query, so that any resultant error could be tested and used by the rest of the logic (to determine if the email should even be sent.)

[cluelessPHP]

pbismad;11063203 wrote:

It would mean that you HAVE setup a UNIQUE constraint and attempting to insert/update a duplicate value resulted in a query error.

So that would mean when you're writing your DDT make sure to identify which is UNIQUE?

pbismad;11063203 wrote:

Yes, actually, it's an application error. A value doesn't meet your application's requirements.

I'll work on errors more

pbismad;11063203 wrote:

The code to handle it needs to test for the duplicate key/index error number (1062) so that it only operates on that particular error number and it needs to re-throw the exception for all other error numbers so that any main/php exception handler gets control.

If there is a duplicate index/key error, when multiple columns are defined as unique, the error occurs on the first column found with a duplicate value. You can parse the error message to get that column name or you can run a SELECT query (in the error handling logic) to find all column(s) that are being duplicated, then use this when building any user error message.

Error numbers are still new to me, I'm guessing it would be an advantage to read more about them and what each means

pbismad;11063203 wrote:

Yes, but the settings should be in a php.ini configuration file, so that you don't need to remember to set them, remove them, or change them when moving code from one environment to another and so that even php parse/syntax errors (in your main file) will get reported.

Error_reporting should always be set to either E_ALL or a -1. When learning, developing, or debugging code, display_errors should be ON. When on a publicly accessible server, display_errors should be OFF and log_errors should be ON.

As this pertains to exceptions, if you don't catch an exception in your code, php will. They will produce a fatal run-time uncaught exception error. If the error_reporting setting is set to report fatal run-time errors (which it will be with either the E_ALL or the -1 setting), php will attempt to report the error, which contains all the actual information about the error. Then, php will use the display_errors/log_errors settings to determine what happens with the reported error information.

Makes sense, only show errors when you need to and hide them so it can't be attacked. When I make an error log put it in a function and then call it on the page, I'm guessing