KevinM1

Also note that OOP is a way to write code while a framework is low-level structural code that is general and useful enough to be used in many projects. Many frameworks are written using OOP. As far as what framework to use, you can't go wrong with one that implements the MVC (Model View Controller) pattern.

Sessions usually only exist for as long as the user doesn't close their browser. If you need the info to last even after a user closes the browser, you can modify how long the session cookie lives: http://www.php.net/manual/en/session.configuration.php#ini.session.cookie-lifetime

Not true. Having posts send GET data instead of POST data is just as valid. POST has some added benefits that makes it common with forms, but saying forms should always send POST data is incorrect Websites should be semantic and RESTful. According to the HTTP spec, GET is for retrieving data, while POST is for updating data*. Forms can be used for both actions, so the proper method to use is based on the intent of the form - is it sending field values to the server in order to retrieve more data based on what's contained in those fields, or is it trying to update the back end data with the values of the fields? Use GET for the former, POST for the latter. Wrong. POST has two advantages over GET: 1. It cannot be manipulated by what's in the browser's address bar. 2. It can send more data. Advantage 1 isn't much of an advantage at all. There's nothing stopping anyone with bad intent from making their own form and posting it to your form handler. There's no inherent security built into POST. Thinking you're safe for using it is wrong. EDIT: Technically, POST is used for creating data, while PUT is used for updating. However, since hardly any popular language/framework exposes/uses PUT naturally, both creating and updating is relegated to POST.

This is, of course, bullshit. Unless the OP is dumb enough to post their db credentials, and does nothing to sanitize incoming data, the risk is minimal, especially as they're merely wondering how to start a project. If the OP wanted to hire someone, they could have visited our Freelance sub-forum. Since they're asking for Application Design tips/advice, and likely wants to hear from more than one person, it makes sense for them to be open and honest about what they want to do and where they're having trouble. This is the kind of request we get all the time in this sub-forum. Have you noticed the lot of us saying "Hey, send me a PM?" Didn't think so.

It's a critical error with the site itself. Usually, it stems from an uncaught exception. In this particular case, both the MSN and Google Apps had some unexpected downtime, so the error is likely a symptom of that.

You do realize that we can't solve any problems you're having with your PHP code without SEEING that code, right?

Objects can be passed from page to page via sessions. Remember: object = particular instance of a class. So, if Forrest Gump logs in, and you store that Forrest Gump object in sessions, that one Forrest Gump object will move from page to page. And, really, forget about singletons. They're dangerous (they're really nothing more than global variables), and there's usually a better way to solve a problem than using them. They have their uses in rare occasions, but they cause most programmers to cringe.

Correct. It's the mechanism that makes OOP in PHP relatively painless.

Addslashes should never be used for security purposes. Use the proper escape function relevant to the kind of db you're using (e.g., use mysql_real_escape_string if you're using a MySQL database), or use prepared statements (look at mysqli and pdo for examples). Also, ensure that the incoming data is of the correct type. For example, if you're expecting an integer, make sure the value coming in is indeed an integer.

The notice is telling you that there isn't a $tmp[2]. Your array is shorter/has fewer elements than you think.

ANY group of form fields whose name is written in array notation (e.g., "textbox[]") will be handled as an array, not just checkboxes.

The answer is a qualified 'yes', depending on how you've set things up. If you want help, show your code rather than talk in vague generalizations.

I hear ya. I have a new puppy, so it's like being the father of a newborn infant that chews through furniture and doesn't wear a diaper. Sleep? What's that?

Hey, you don't have to die alone. I'll come with to make sure you do the job right.

If your backing DB column allows null, than all you need to do is simply not add that form field reference to your insert/update query. The DB column will be null by default in that case.

Objects are not duplicated/copied when passed into functions or assigned to. They're always passed around by their references. The simplest thing to do would be to have your Main object pass its Visitor to its Room as an argument to whatever method you need to use to access your messages: class Main { private $visitor; private $room; // constructor, other methods, etc. public function sendMessageToVisitor($message) { $this->room->newMessageToVisitor($this->visitor, $message); } } class Room { private $message; // constructor, other methods, etc. public function newMessageToVisitor($visitor, $message) { // do something with $message, $this-message, and $visitor; } } That said, there's likely a better design you could use, but without knowing what you're actually doing, I can't recommend a better way to approach the problem.

So, what are you asking for, specifically? We can't help unless we know: What you expect your code to do. What's actually happening (including errors, warnings, notices, and any unexpected output). What your current code is.

It's returning 0 because you're not actually returning any value from your performCalculation function. Functions have their own, unique scope - what happens within them won't be 'seen' by the rest of the script unless you return a value from the function, and assign that return value to a variable in the parent scope, like so: function performCalculation() { // bunch of code return $total; } // main script $myTotal = performCalculation();

file_exists takes a directory path, not a URL.

All patterns have strengths and weaknesses. That's why they're patterns and not silver bullets. Each pattern is a common, tested, working approach to solve a particular problem. Your problem is double submissions. The PRG Pattern exists to solve that particular problem.

How so? Its purpose is to stop double form submissions.

Do a google search on the PRG Pattern (I'd type more, but I'm on my PS3).

It's telling you that there are no POST keys named 'myusername' and 'mypassword'. Check your form to make sure your inputs have the right names.

$_SESSION['$counter'] is not the same as $_SESSION['counter']

In the future, please place all of your code within either or tags. I took the liberty of doing it for you above.