maxxd

There could be any number of reasons this isn't returning what you expect - a little more detail would help. If you run the query in phpMyAdmin or MySQLWorkbench, is it returning 1 row or 3? Is there some php display code - obviously, if there is display code we'd need to see that as well.

That's how I would handle it, yes. Something along the lines of the following: $query = mysql_query("SELECT id ,location ,description ,name FROM `images` ORDER BY `id` DESC LIMIT 4"); while($row = mysql_fetch_assoc($query)) { echo "<img src='{$row['location']}' alt='{$row['description']}' name='image_{$id}' id='image_{$row['id']}' title='{$row['name']}' />\n"; } Of course, I'd also recommend you use either the PDO or MySQLi libraries instead of mysql_* functions as those are well and truly deprecated and slated to be removed from the language soon.

Remove the width attribute in your table opening tag.

You're overwriting $imageData on each loop through the 4 returned rows from the database and only outputting the results after the loop. Are you actually storing the image in the database, or a path to the file on the server? I'm not sure how the browser's going to respond to trying to write the image header for each of the images, but you'd need to put the lines header("content-type: image/jpeg"); echo $imageData; before the closing curly brace of your while() loop. Also, if you're trying to display 4 images, why do you care if $_GET['id'] is set? If you're only trying to display the selected image (the image corresponding to 'id' in $_GET['id']), the user Ch0cu3r's code.

OK - it's actually not a bad start at all for a beginner. Couple things (please keep in mind that this is how I code and there are a million other opinions and ways of working) First, your constructor method actually was doing what it was supposed to do, it just wasn't storing the result anywhere or returning anything so it looked like it wasn't doing anything. Notice in the code below that there are two property declarations before the constructor - these set up object-scope variables (also called properties). The scoping here means that the methods in the Greeting class can access the values in the properties, but, because they're declared private, an external class will *not* be able to access them directly. The same visibility caveat applies to the functions (called methods) in the class itself - an external class won't be able to call setGreetingPhrase() without an error. Now, I have a tendency to break my functionality into the smallest units I can think of when I create my methods. Some would say they're too small, but I like to know exactly what I'm looking at when I have to debug a method. So, in this example, your constructor explicitly calls setTime() to set the hour of the day in the local property, then explicitly calls setGreetingPhrase() which uses the value in hour_of_day to set the string value you eventually want to return. Finally, you've got the getGreetingPhrase() method which acts as the public access point in order to return the string built by the constructor. Obviously, there's a ton of different things you can do here - it's just a quick and dirty example. For instance, make setGreetingPhrase() and setTime() public and other objects can modify the eventual output, you can do value checking, etc. class Greeting{ /** * The hour * @var int */ private $hour_of_day = 0; /** * The actual greeting phrase * @var string */ private $greeting_phrase; /** * Class constructor. * @param string $dateString Date string */ public function __construct($dateString=null){ if(!is_null($dateString)){ $this->setTime($dateString); $this->setGreetingPhrase(); } } /** * Sets the time of day. * @param string $value Valid date string to parse and store * @return void|string Error code and message on DateTime exception */ private function setTime($value){ try{ $dt = new DateTime($value); }catch(Exception $e){ print("<p>Error: {$e->getCode()} :: {$e->getMessage()}</p>"); die(); } $this->hour_of_day = $dt->format('G'); } /** * Sets the actual phrase to return as a greeting. * @return void */ private function setGreetingPhrase(){ if($this->hour_of_day < 12){ $this->greeting_phrase = 'Good morning!'; }elseif($this->hour_of_day >= 12 && $this->hour_of_day < 18){ $this->greeting_phrase = 'Good afternoon!'; }else{ $this->greeting_phrase = 'Good evening!'; } } /** * Returns the greeting phrase if set up. * @return string|null */ public function getGreetingPhrase(){ if(!empty($this->greeting_phrase)){ return $this->greeting_phrase; } return null; } } $greeting = new Greeting('2014-06-19 12:45:00'); //$greeting = new Greeting('12:45pm today'); echo $greeting->getGreetingPhrase(); So, that's my two cents - hope it helps!

I've always considered legacy code to be existing code in a project - class code written for version 1.0 and not updated for 1.2 is legacy code. And, honestly, version 1.2 code is legacy as soon as development on 1.3 starts. Legacy code can be ugly or pretty, as can code under test, code in development, or deployed code. Ugly is ugly regardless of state or stage. That's the way I've always thought about it, anyway.

.bind() has been deprecated as of JQuery 1.7, with .on() being the preferred method of binding events to potentially non-existing dom objects at page load. That may have something to do with it - check which version of JQuery is being used in each case. Also, I've run across a couple odd occurrences where using the dom element selector doesn't actually work, and it needed to be something along the lines of $(document).on('click','#main_menu_id',function(){ ... }); Don't quote me on the actual syntax above - I've only run across the situation once or twice, so I can't pull it out of my brain right now. I'll look tomorrow morning and see if I can find a concrete example.

OK. First off, do what ginerjm suggests. Always turn on error reporting on your development server. Now, fun times. You're assigning $student_id the value from $_REQUEST['id'], using $_GET['id'] in the query, assigning $_SESSION['student_id'] the value from $_POST['student_id'], and using $student_id in the redirect header. It also seems that the database contains a learner_id field, which you compare to $_POST['learner_id']. The sheer volume of inconsistent data sources, names, and data transfer methods makes debugging a nightmare. I would recommend selecting the student id from the student_information when you select last_login_date. The id should be an auto-incremented primary key for the table, so you'll know it's an integer and safe for CRUD operations. Compare that to either $_GET['id'] or $_POST['id'] (I'd recommend you choose a transfer method and stick with it - as you can see, it's easy to get confused if you don't know where the data is coming from) to make sure you're dealing with the right student, then you can a) assign the database-retrieved value to $_SESSION['student_id'], b) use the database-retrieved value to update the student_information table, and c) append the database-retrieved value to the location header. All of that aside, print out the value of $student_id before and after the htmlentities() call and see what the value actually is. From the documentation: If the input string contains an invalid code unit sequence within the given encoding an empty string will be returned, unless either the ENT_IGNORE or ENT_SUBSTITUTE flags are set.

There's no field named 'check' in your form. Which means there'll be no $_POST['check'] for you to use as an array.

We'll need to see the HTML form code. Basically, it's saying that $_POST['check'] isn't an array after submission. Post the HTML and please use the '< >' button on the editor to put all the code in code tags - makes it easier to read.

OK - Looks the the SECURE constant is undefined. What's the purpose of it - I don't see where you've used it anywhere else in the code.

Several things going on, but the one that's probably tripping you up is that you're not hashing your password before comparing it to the one in the database. I'm assuming (hoping, really) that the stored passwords are all hashed and not just plain-text. Ignoring the deprecated mysql_ functions, the invitation to SQL injection, and undeclared variables, this is probably why you're not logging in correctly even with legit credentials.

It's the joy of PHP's not being a strongly-typed language. Any property or variable can hold any kind of data at any time. I agree with Jacques1 that it's better to be explicit and define the type before assigning values.

You stated this in reply #7: Then the next age thatdisplays calls the login_check function which is shown below and at the point the session variables have no values. I'm assuming a bit of a typo on 'the next age thatdisplays' that was meant to read 'the next page that displays'. If you're redirecting, are you restarting the session on the target page with session_start()? If not, usually php will throw an error, but if your error reporting is off you'll never know that. Insert the lines jazzman1 suggests on the page to which you redirect and see if it give you an error about undefined variable $_SESSION. If so, start the session again and let us know what happens.

if(strlen($postcode) > 5){ $postcode_wc = substr($postcode,0,-3); } Give that a shot.

KevinM1 - that's how I always thought about it, but I haven't had nearly enough coffee today. Thanks for the detailed explanation!

I agree with Maq. What you've described above isn't really polymorphism (at least not so much as I understand the concept). What you'd do is create Apple, Pear, and Kiwi class files, the approach like this: $fruit = 'Apple'; $produce = new $fruit(); $res = $produce->calculate(); $fruit = 'Kiwi'; $produce = new $fruit(); $res = $produce->calculate(); $fruit = 'Pear'; $produce = new $fruit(); $res = $produce->calculate(); This way Apple,. Kiwi, and Pear can all have wildly different methods of calculating whatever it is they're calculating and the calling implementation doesn't have to know a thing about any of it.

Try removing the header("Location: view_dept.php") line from data1.php. You can close the database connection and then use exit(); to halt script processing. As it stands, by the way, your connection is closed by the page refresh and not the explicit close command. Also, you'll want to start using PDO or mysqli_ - the mysql_ functions have been deprecated for quite some time and are scheduled to be removed in the near-ish future.

Try this in your script print("<pre>".print_r($products,true)."</pre>"); and post the output here.

class Automobile implements iAutoDetails{ private $_model; function __construct($model){ $this->_model = new $model(); } } interface iAutoDetails{ public function getWheelBase(); } class Mustang2013 extends Automobile{ private $_wheels = '17 x 8'; public function getWheelBase(){ return $this->_wheels; } } class Mustang2012Boss302 extends Automobile{ private $_wheels = '19 x 9'; public function getWheelBase(){ return $this->_wheels; } } $auto = new Automobile('Mustang2012Boss302'); print("<p>{$auto->getWheelBase()}</p>"); //prints 17 x 8 $auto2 = new Autmobile('Mustang2013'); print("<p>{$auto2->getWheelBase()}</p>"); //prints 19 x 9 I think the issue is your current object setup. Personally, I'd do the above - that way it really doesn't matter at all what automobile you're instantiating, you know you can call getWheelBase() and you'll get the proper wheel base measurements. Obviously, you'd put any and all common functionality in the parent class (Automobile) while saving the model-specific functionality and information for the child classes. The interface insures that you've got a consistent api when dealing with new objects.

Personally, I'd set up abstract methods in either the parent class (assuming PersonFactory is abstract) or in an implemented interface in order to present a consistent class interface, much like kicken suggested. For instance, if PersonFactory includes public abstract function personTypeMethod(); this can be implemented in each of your person type subclasses. Manager can implement it as such public function personTypeMethod(){ return 'I am a Manager! Yay me!'; } while Player includes public function personTypeMethod(){ return 'I am a Player! That is awesome!!'; } Then your main code simply does something like this $my_person= PersonFactory::createPerson($database, $person_id); // my_person can be an array of objects, getName from parent class valid for all objects $details = $my_person[0]->getName(); //run your stuff foreach($my_person as $person){ echo "{$details}: {$person->personTypeMethod()}"; } This way your code doesn't care what type of person sub-object it's dealing with, you simply know that you can call personTypeMethod() and get a legitimate and expected response, and you've done away with long or nested conditionals and/or a giant switch() statement. Obviously, the code above is a mish-mash of stuff and it looks like there'd only be one returned result from PersonFactory::createPerson(), but the thing is you could loop through an array of Person objects this way without having to specify which method you're calling and everything will work, even if you've got 2 players, 3 refs, and 1 manager in the returned array.

The problem is that the POST variables are still set. You'll need to redirect the browser after a successful CRUD operation. You can simply reload the current page or redirect to a new page, whichever is best for your situation. There's actually a name for this operational method, but I can't for the life of me remember what it is right now...

Sorry for the vast amounts of technobabble, but glad you got it working! You'll want to mark this thread resolved and start a new one for the other issue - post your code there and we'll see what's up.

If the address is spelled correctly and you're still getting redirected, the DNS hasn't resolved. Try accessing the site by IP instead.

Are you developing locally or on a remote server? If you're local, you'll more than likely enter 'http://localhost/path/to/site' in the browser's location bar. If remote, make sure you're spelling the site address correctly.