Reply To: Uploading Form Data to The Database

[__]

Instead of bombarding this forum with PHP questions i cant find answers to, i was thinking of just posting them on this one forum. So heres another question.

Two thoughts on that:

• makes thread navigation harder (more to read through, plus you have to figure out which comments go with which issue)
• generates less interest (users may have looked at the original question and decided they can’t help with it, and so ignore the thread from then on).

In the future, just make a new thread. That’s what they’re for.

i’m sure some improvements can be made to make it more reliable/readable.

1. I strongly recommend you do not use the “alternate” block syntax (the foo…endfoo syntax). It is not very readable or maintainable, and can lead to lots of mistakes when you work on the code in the future. The standard form is what you should be using.

while(){
    /* do stuff */
}

…I think the alternate form only survives because it’s so widely used in WordPress.

1. I try to keep all of my business logic separate from the output (display) code. This is good for both readability and resilience: for example, if you encounter an error when fetching you database records, you’ll be stuck with a broken html <table> and no way to redirect or show an error page instead.

$q = connect->query( $sql );
$rows = $q->fetchAll( PDO::FETCH_ASSOC );

//  . . .

?>
<!--  your html markup  -->
<?php
foreach( $rows as $row ){
    echo '<img src="'.$row['COVER_URL'].'" alt="'.$row['TITLE'].'"';
    //  etc., etc.  . . .
}
?>

This should work just fine, so long as you don’t have tons and tons of result rows.

1. In your catch block, $e->getMessage() is a no-op. You don’t display or log the message, nor make any decisions based on its value, so there’s no reason to access the message at all.

---

All in all, however, doesn’t look bad.