KevinM1

Stop using 'global'. It shouldn't be used AT ALL, regardless of whether you're writing OOP code or procedural code. Objects can contain other objects. If you have an object that requires another object in order to work, then create a private field for it and assign a concrete object to that field in your containing object's constructor.

I think something you need to realize is that design is about more than just having a non-ugly header, navigation, and content. Design is supposed to be informative. Your end users need to know the following information at a glance: What is Celbre? The name of the site itself gives no clue, as 'celbre' isn't a word. A second glance shows it's a blog. Okay.... Why use Celbre over other blog options? What do you offer that's different than the competition? Does it cost money? Where are the screenshots of how individual blogs can look, or how the back end looks? Where's the feature list? Saying that your blog solution is good for business and educational use implies that you have some additional features that make it a better choice in those settings than, say, Blogger. Don't use marketing speak if you can't back it up. And, all that is in addition to general, nuts & bolts design issues (ginormous header for no real reason, aside from thinking it's modern looking, no clue as to what the 'Username' input on the landing page is supposed to do, mis/non-aligned form inputs on the register page (I keep saying it, but center alignment is ugly... use CSS to align your inputs in a uniform manner), etc.). I'm not trying to be some stalker asshole who shits on all your sites. The problem is, to date, all of your sites have had some serious UI flaws. There's a distinct theme of either throwing a bunch of stuff on the screen and hoping it works, or, in this case, attempting to mimic more modern designs and hoping it will work. There doesn't seem to be a lot of critical thought behind the decisions themselves, or how they act in tandem. So, some general advice: Stop listening to what your friends and family say. They will not be critical of your work. Ever. Also, stop giving into your clients 100%. Remember, you're supposed to be the hired professional help. Most clients have horrible tastes, and think that the internet hasn't evolved since Geocities. Most wouldn't know good design if it bit them in the ass. This isn't to say don't listen to them. Rather, try to incorporate their ideas in a tasteful manner. And, if something they suggest would work against the site, have the balls to disagree. Do attempt to learn modern design and tricks. I have the feeling that Celbre was your first attempt after looking at some modern sites. It definitely has flaws, but it's much better than your previous efforts. Some more links to help you out: http://css-tricks.com/ http://www.1stwebdesigner.com/ http://tympanus.net/codrops/ http://www.smashingmagazine.com/ http://designmodo.com/ http://designfestival.com/ http://www.uxbooth.com/ http://doctype.com/ <-- Stack Overflow for HTML/CSS and general design Read through the tutorials. Read the blogs and (often more importantly) the comments. Engage true UI/UX professionals on those sites' forums (if they have forums). Finally, keep in mind that as harsh as my (and others') criticism may seem, it's certainly better to hear honest reactions now than to be mislead by those around you with good intentions.

This topic has been moved to PHP Coding Help. http://www.phpfreaks.com/forums/index.php?topic=344845.0

Hall of Famer, do you know how hidden inputs actually work? It doesn't appear that you do. A hidden input is not rendered to the screen. However, it is present in a page's markup/HTML. That means all anyone needs to do to see what's in a hidden input is select the 'View Source' option in their browser. They will see something like: <input type="hidden" name="secret" value="something important" /> In among all of the other form inputs. What does that mean? It means that anyone with an inkling of knowledge about HTML, scripting, and databases (which, I assure you, anyone who would want to screw with your site has) will be able to mess with your form data without needing a special browser plugin to do it. How is it possible? There's nothing stopping a would-be attacker from creating their own version of your form in HTML and having it post to your form handler. So, in short: 1. Hidden inputs are not supposed to be used as a security measure. 2. No one needs a plugin in order to hack your site. You're really barking up the wrong tree here. Plugins have nothing to do with site security. At all. End of story. Like others have said, what you need to do is write input sanitizing and validation code in your script.

Welcome to the internet.

Stack Overflow.

A couple of things after a quick glance: 1. Make your fields private, or protected if you plan on extending the class. You have setters in place already, enforce their use by keeping the fields from being directly accessible. 2. Your send() method, as it stands now, will return true if only one message was sent successfully. What if some are sent successfully, and others aren't? 3. Since you're already hard coding default values for your charset, headers, etc., why not simply assign those values when you declare those fields? That would save you from having to call their associated methods when sending the mail for no real reason. If the values need to be changed, you'll still have the setters in place. In other words, this: class Email { private $to = array(); private $subject; private $message; private $fromName = 'Website Name'; private $fromEmail 'admin@website.com'; private $cc = null; private $bcc = null; private $contentType = 'text/html'; private $charset = 'iso-8859-1'; private $_headers; // constructor omitted because it would remain the same. public function setCC($cc) { $this->cc = $cc; } public function setBCC($bcc) { $this->bcc = $bcc; } public function setFromName($fromName) { $this->fromName = $fromName; } public function setFromEmail($fromEmail) { $this->fromEmail = $fromEmail; } public function setContentType($contentType) { $this->contentType = $contentType; } public function setCharset($charset) { $this->charset = $charset; } private function _setHeaders() { $this->_headers = "Content-type: " . $this->contentType . "charset=" . $this->charset . "\r\n"; $this->_headers .= "From: " . $this->fromName . "<" . $this->fromEmail . "> \r\n"; if ($this->cc != NULL) { $this->_headers .= "CC: " . $this->cc . "\r\n"; } if ($this->bcc != NULL) { $this->_headers .= "BCC: " . $this->bcc . "\r\n"; } } public function send() { $this->_setHeaders(); $sent = FALSE; foreach ($this->to as $recipient) { if (mail($recipient, $this->subject, $this->message, $this->_headers)) { $sent = TRUE; } } if ($sent = TRUE) { return TRUE; } else { return FALSE; } } }

1. Get rid of the splash page. Unnecessary, and anything that requires extra clicks for the user to get to their destination is a bad thing. 2. Make a better navigation system than numbers without any indication of where they lead, especially since some lead to your shared host's 404 page.

Nope, not by any means. However, they were one of the first bigger sites to get in trouble because of things like beacon Which is far more nefarious than what this thread is about. Facebook is not a 'good' company. I dislike many of their decisions about what information they claim to require, and how they handle it. Their privacy settings page is about as opaque as it could possibly get. But two pages of discussion over a cookie?

Pop quiz: did Facebook invent the tracking cookie?

How hard is it to, you know, simply delete the offending cookie(s)?

Don't use 'global' to pass values into a function. Pass those values through the function's argument list. NEVER use 'global' at all for anything, ever. Also, what do you mean by mysql_real_escape_string missing certain things? How are you using it? What do you consider to be 'scary' that it's letting through?

OOP is a topic far too broad to adequately address in a forum post. Suffice it to say, OOP isn't about using objects as mere function collections. If you really want to learn OOP in PHP, get the book PHP 5 Objects, Patterns, and Practice by Matt Zandstra. It's the best introduction to OOP available.

Like most things, it's neither all good or all bad. Any benefits gained by flushing the buffer are dependent on what kind of architecture you're using. You won't see much benefit in an OOP/MVC environment, for example, as all processing is done before anything is rendered. Flushing, in that case, is pointless as the only logic left to perform at that stage would be simple view logic - conditionals (if/else) and loops. Also, depending on where you flush (most people recommend at the <head> of the document), you'll remove the ability to use HTTP headers, including redirection headers. All in all, it seems like the kind of micro-optimization that may be better addressed through caching and compression.

Why are you using the buffer?

What extra query? You need to return two things: The hashed password. The salt. That's as simple as "SELECT password, salt FROM table_name WHERE user_name = $user_supplied_name" Two columns fetched with one query. Now for what to use for a salt, I've always liked using the timestamp of when a user registers. It's a unique value for each user and trivial to generate.

Correct. Only views should contain HTML. Here's what MVC usually breaks down into: Model: This is your site's internal logic. Not the logic that decides which URL was requested, or what view to render, but the logic of doing things with data. It could be as simple as run-of-the-mill database CRUD operations, to complex business/financial activity. Controller: This is the part that handles HTTP requests (GET and POST), accesses the Model layer for data processing, and decides which View to render while sending the Model data to that View. View: This is what the user sees. They're HTML templates with very, very little PHP to help render the Model data (if/else conditionals and loops only). With most MVC systems, Controllers are accessed according to the URL supplied to the system. The system has a Front Controller (look it up) and a route table. The Front Controller parses the incoming URL and attempts to find a match in the route table. When a match is found, the correct Controller object is retrieved, and the desired method is invoked, with whatever request data sent in as arguments to that method. Example: example.com/news/story/1223 The news story method of the news controller is being accessed, with 1223 as the argument being sent in. In other words: class NewsController extends Controller { public function story($id) { // access the Model to obtain the news story data associated with $id // render the correct View with that news story data } } Before building your own MVC framework, you should really take a look at how they're usually done. There are some conventions to follow that will make your life easier.

3 in this case means shifting the binary representation of the number 3 positions to the left. That's the same as multiplying it by 2^3, or 8.

This topic has been moved to MySQL Help. http://www.phpfreaks.com/forums/index.php?topic=343996.0

thanks dan, that makes more sense the fact that get_header() spits out the contents of header.php - does not mean it has access to variables in other files in that case, i only have the choice of using a global variable? Ideally, you'd simply modify the function to accept your $myvar variable as a parameter: function get_header($arg = null) { if (isset($arg)) { // do something with $arg } // continue as normal } // later in your code $myvar = "something"; get_header($myvar);

What is this 'event' and what does it have to do with your code?

Can you post a var_dump of your $task_array?

You need to use isset: $task_array = explode('.', JRequest::getVar('task')); if (isset($task_array) { $task = $task_array[1]; } EDIT: Keep in mind, the code above will only check if the entire array exists. If you need to check a particular element of the array, modify the if-conditional to reflect that.

What is the site supposed to be, aside from a blogger? Also, I say this all the time with your sites: fix your contact form. Centered inputs of varying sizes looks ugly and haphazard. You need to use some CSS to make your form look uniform.

You do realize that medical information must be handled under strict guidelines, right? You do NOT want to run the risk of violating HIPAA or whatever patient confidentiality laws your country has. Given the delicacy of the data involved, this is something you should hire a professional with a solid history of working on medical software for.