Daniel0

Dude, you've been called out on this multiple times. I've personally done it a few times myself. Besides, it's not validation, it's filtering. Validation is e.g. "does this only contain digits? No, 'g' isn't a digit, we'll tell the user to type in something correct". Filtering is taking any value and making sure it fits whatever you're using it for, e.g. escaping quotes for a SQL query. Also note that "whatever you're using it for" is key here. You're not supposed to run htmlentities in a SQL context, but in a HTML context. Also, your function presupposes that HTML tags should never be in any string. That's incredibly presumptuous, and it might not always be the case. If you ever need a string with absolutely no HTML, then run it through strip_tags() when you do. Running it through all the possible filtering functions you can think of is not a good idea. Perhaps it's unprofessional the way we said it here, but it's no less unprofessional than constantly posting bad advise despite the fact that you've been told it is numerous times.

They can modify anything except your user name and user group.

You can return any value you want including no value.

Dude, stop wasting your time. Memorizing all the functions is entirely useless.

Not trying to regulate the forums or anything...but CV, whens the last time you've read the rules? At least I made sure I got this included in the ToS: I'm an admin, so I can just send myself an email By the way, that board does exist.

I'd argue that programming in Haskell or Lisp is fundamentally different from programming in PHP or C.

Seems like this mod will do it.

Seriously, don't bother. It can be circumvented anyway. Some methods make it more difficult, but if you're determined you'll get it.

Unless you somehow can ascertain the quality of that example, I would be extremely cautious with that approach. Worst case you end up picking up a lot of bad habits and bad practices. See the PHP Help forum for proof.

Well, they do. There is a keyword called global that can be used to make a variable global in the scope in which it's used, and there is a superglobal called $GLOBALS that contains all such variables as well. It's bad practice though, and you shouldn't do it. I don't even understand why they put it in the language in the first place. It doesn't do anything but promote bad practice. It will inevitably turn out to be different to maintain, and it will be difficult to keep track of it and debug it. I've had to work on code where mostly everything resided in the global namespace, and it was nothing short of a pain in the ass. Your best option is to pass the object by argument. If you need it throughout an entire class it might be worth passing it to the constructor, otherwise it would also be best to just pass it specifically to that method. Objects are passed by reference, so it won't get duplicated like scalar values and arrays will. It'll only be using 4 byte more memory (the size 32-bit integer) for a pointer to the memory address of the object, so it will by no means be an issue. While we're talking about best practices, I couldn't help but notice you used or die() in the code snippet you provided. Do have a look over this blog post I wrote about that.

The singleton is not the best method. See this post for my comments on that. Yeah, you're exploiting the fact that sessions are superglobals. Your connection is not supposed to persist across requests like that, and I don't even think it's possible. It's a bad idea because you make it a global object. Nothing. That is the best option. Quite the contrary in fact. The method you used to use is less clean than passing an object around. You have no control over the resource in that way.

I'm pretty sure they would be using something like memcached. You should be fine storing the session data in a database. The forums a main site here do that actually.

Essentially you should strive for as loose a coupling between entities as possible. If you read a global from within a function you will have created a coupling between that global object (not talking about OOP objects here necessarily) and your function. This means you can only ever use that function with, in your case, $_POST. If you on the other hand pass the value by argument you won't make a coupling (= dependency), but will work with any type of scalar value (edit: array of scalar values obviously as that is what $_POST is). You should limit your usage of the super globals, and you should never create additional globals yourself.

Looks sort of like the facilities that Zend_Form gives you coupled with Zend_Validate and Zend_Filter.

No, you said you know all the security flaws in your app. You will never know the security flaws in your app because you'll fix them as soon as you discover them. I never implied the perfect system exists or that it's possible to write a system without any security flaws.

Start with the manual. Make sure you've understand the syntax and make sure you know the features PHP has. Make sure you're at least decent with math (not just 1+1=2 shit, I mean real math). That will help you a lot, and the way you need to think when doing math coincides with the way you need to think when programming. A good exercise might be to try to implement some of the functions provided in PHP's library. Try for instance to implement explode without using any PHP built-in function. What does it mean to split a string into an array at a particular delimiter? Can you explain it in English (or whatever natural language you're most proficient in)? How about strlen? What does it mean to get the length of a string? Can you explain how you would do that outside the context of programming? If you can explain it using words, you can explain it to the computer with a programming language assuming you know the syntax. Programming is essentially problem solving, i.e. how do you most efficiently get a computer to perform a particular task. The kind of programming I described is called imperative programming. It works sort of like a recipe for when you're cooking. You are explaining the computer what to do with a particular input and then produce a particular type of output. Another programming paradigm is called functional programming, which I would encourage you to look into some time. With imperative programming you explain what to do, but with functional programming you explain what things are. When you are able to do problem solving and decompose a large problem into smaller subsets of problems you will want to learn how to organize your code in a practical manner. You will want to look into object oriented programming (OOP) and object oriented design (OOD). You will want to look into methodological topics such as what e.g. agile programming is, what TDD (test driven development) and unit testing is. You would probably be inclined to read tutorials like "how to create a membership system", "how to write a CAPTCHA" and so on. Practical tutorials that end with a very clear and quantifiable result. I would not recommend this. You don't want to know how to create a membership system. That skill in itself is entirely useless. You will want to know what a membership system consists of, and you will find that those individual steps are fairly manageable. Starting at a lower abstraction level has several benefits. It will train you to think about how the algorithms you implement work and it will train you to think like a programmer. Of course you will not want to use your own explode() implementation in a real program. Usually it's a waste of time reimplementing things. You will hear people say "don't reinvent the wheel", and that is true, mostly anyway. In any real application it's true, but it's not true in a learning environment. Using this approach it will probably take some time before you create anything meaningful, but in the long run you'll benefit from it. I've been know to say that "PHP is too easy", and I believe this to be true. It's too easy for anyone to start right off the bat and create something concrete. The problem is just that these people's codes are fundamentally flawed. They use bad practice, their code is highly inefficient, not at all maintainable and full of bugs and security vulnerabilities. Sure, they produced something, but the fact remains that it plain simply sucks. Programming done right is not easy, and anyone who tells you it is is either lying or not a good programmer. Don't ever think you're good enough. Don't stop at a plateau. Make sure you keep learning, keep reading, keep practicing. There is someone better than you. Strive to be better than them, strive to be the best. Remember that finishing something faster does not necessarily mean it's better.

Ah, okay I see. I just sometimes see some people do something like this: $_GET = array_map('mysql_real_escape_string', $_GET); I thought that was what you meant.

http://en.wikipedia.org/wiki/Proofreading ^ you should try it some time.

If you knowingly release software with security holes in it you're a crap developer.

Yes.

Portability. I would regard that as sort of bad practice. The "cleanliness" of a value depends on the context in which it is used.

Actually, that doesn't matter with an attribute value as the < doesn't carry any special meaning there, so it doesn't have to be escaped.

Hmm... it must be Zend_Date interpreting the ISO 8601 dates from MySQL incorrectly. Should be an easy fix.

Just include or require the file. The variables that are accessible the place you include from will be available in the included file as well, as haku said.

Let me turn the question around: Why would you want the value back?