Jacques1

Hi, you're confusing many different things which have nothing to do with each other. Autoloading automatically includes class definitions, nothing more, nothing less. It does not create instances in any way. The Factory Pattern is a specific way of instantiating classes. It's meant to make the instantiation more flexible and allow you to easily exchange one class for a similar class. The term “reuse” refers to code reuse. The point is that you are able to reuse your code in different contexts instead of starting all over again everytime. It has nothing to do with resource sharing or anything like that.

Regarding SQL injections: It's completely irrelevant whether you're dealing with checkboxes, text fields or whatever. Anybody can send any data to your server. What you need to understand is that the client and the server communicate through HTTP messages. Any user interface built on top of this is just for convenience and has no bearing on the data. I could connect to your server right now and send any HTTP request I want, regardless of how your HTML forms may look like. A form is really just a guide for the client. You're telling the user which kind of input you'd like to get. Whether or not the client follows your rules is completely up to them. They may send you the expected “on” for your checkbox parameter. But they might as well send you malicious SQL snippets. So it's always the same rule: Never trust user input. This includes POST parameters, GET parameters, cookies, the URL, all HTTP headers and any other part of the HTTP request. All of this is under the user's control and can be used for an attack. Learn how to use PDO correctly. The whole point of prepared statements is to not insert values into the query string.

Where's the closing quote?

No offense, but I find your approach to privacy and security rather narrow-minded and cynical. Have you considered that privacy is a value by itself and that protecting user-related data is a matter of fairness? It's not always about money and laws. Which websites I've accessed at which point of time with my IP address is none of anyone's business. I definitely do not want this data to be in some public text file, regardless of whether or not U. S. legislation agrees. Is it so hard to respect this? Is it unthinkable to do something simply because it's the right thing to do? If people want their silly IP blacklists, by all means, let them have them. But violating the privacy of (innocent) visitors is unacceptable.

Hi, blocking IP addresses is not only naïve, it's downright harmful, because it will affect many legitimate users as well. Contrary to popular belief, one IP address does not equal one person. There are proxies, VPNs, hotspots, company networks, private networks, Tor nodes etc. If you (accidentally) block their addresses, you'll lock out hundreds or even thousands of innocent people. So the solution is: Don't do it. If you insist on the brute-force way, you'll need more than a simple text file. You have no right to publish the blocked IP addresses, so you can't just put them into a public file. At the very least, you must limit access to the specific IP addresses of the other servers. But you actually need an authentication mechanism, that is, the other servers must provide a password or certificate to prove their identity. Only then may you hand out the blocked IP addresses. Are you sure you wanna go through this for a silly blacklist?

Well, this is how HTML works. Block elements like div are displayed on a new line. If you don't want the div element, remove the tags.

Hi, I agree. It's probably best to rewrite this. Why on earth do you call a method “Get...” when it actually sets an attribute? Why do you keep overwriting the same attribute with a loop? Why do you use preg_match_all() when you only need a single match?

Hi, you should read my comment in your last thread. Your current way of writing PHP code is extremely insecure and can lead to all kinds of attacks against your server or your users. Do not insert raw values into your HTML markup. Always escape them first. This is crucial! Besides that, I have no idea what you mean by “doesn't work”. Can you be more specific? Right now, all I see is that the syntax is badly broken with randomly placed quotes and missing “.” operators. I think you should simply rewrite this line. But the escaping is much more important.

It's like talking to a wall.

This has nothing to do with PHP. Joins belong to the basics of SQL. If you don't know them, you should learn them now, because you'll need joins over and over again.

Well, $result is a MySQLi result object. What do you expect to get when you insert that into a string? If you want the data from the query, you need to actually fetch it with one of the various fetch method like mysqli_fetch_assoc().

Hi, there are several other issues in the code. First of all, there's no security at all. You blindly trust the user input and insert it into your queries and your HTML markup. This can be used by attackers to manipulate your queries and steal arbitrary data from your database (e-mail addresses, password hashes etc.) or even take over the entire server. In addition to that, they can inject arbitrary JavaScript code into your page and, for example, steal the session IDs of your users to trick them into handing out their password. Never trust user input. If you actually plan to build a shop, such carelessness will get you into serious trouble. But even if you do this just for fun, you need to starting thinking about security. Attackers won't spare your server just because you're new to PHP. See this overview of common security vulnerabilities. In addition to that, you'll want to learn how to use MySQLi correctly.

Hi ShivaGupta, you should read the comment in the very first line. The code has been scrambled to prevent you from reading it. Either accept this or get a different script which is open source.

There is no sense in this. Phaelon simply has fallen in love with variable variables. // I see you've already found it.

Hi, I think this is caused by a combination of different problems. First of all, PHP itself is a mess. The people who say it's easy to learn either don't know the language or simply lie. It may be easy to produce crap, but writing good code takes a lot of experience and deep knowledge about the hundreds of quirks, pitfalls, brainfarts and bugs of PHP. The next problem is that the people who publish “tutorials” and free code tend to be absolutely clueless. PHP is often described as the blind leading the blind, and this is very true. Enter a random PHP-related keyword into Google, and you'll get page after page of absolute nonsense. Finally, PHP attracts the wrong people. Too many newbies have absolutely no interest in learning the language and implementing intelligent solutions. They seem to think that “programming” is the act of stealing crap code from some dubious website. As a result, the same stupid code snippets from the 90s are passed from generation to generation and just won't die. Put the three together, and you know why PHP is in such an awful state. A large part of the PHP users is basically stuck in the 90s, but the Internet today is very different from the Internet of the 90s. What may have been acceptable back then will get you into serious trouble today. I think we need to insist much more on security and quality. Yes, it's annoying to repeat the same litany in every single reply. But it's the only chance to spread the word.

And now you have two problems: utter ignorance and a bunch of crap code.

Never, I repeat, never use SET NAMES. It's so sad that everybody blindly copies and pastes this code snippet without understanding the consequences. What this does is silently change the character encoding of the database connection without telling PHP about it. That means critical functions like mysql_real_escape_string() will assume you're still using the original encoding and may no longer work. As a result, you could break your database security entirely. Always use mysql_set_charset(). Or even better, get rid of the old MySQL extension and enter the 21. century: PDO. There's a lot more to say about your task, but I'm starting to think this forum isn't the right platform for in-depth information.

Unfortunately, “doesn't work” doesn't work as a problem description. Have you thought about trying to actually find out where things go wrong? You know, using an echo to see which parts of the code get executed, using var_dump() to inspect variables? The reason why you're not getting any error messages is because you're doing everything to suppress them: You catch every single exception that might occur and replace them with a plain return (I guess you actually meant echo). This is something I just don't get: Why do people turn on exceptions, then clutter their code with try-catch blocks to immediately catch all those exceptions and throw them away and finally complain about not getting errors? What's the idea behind this?

No. Keeping scripts and static files on separate domains is a wise decision, because there's absolutely no reason to have the client send their entire set of PHP-related cookies to every single CSS file, image or whatever.

Hi, loading HTTP content on an HTTPS site is rather silly, because this gives an attacker the opportunity to jump in and potentially subvert the entire security of HTTPS. Is there any reason why you can't use HTTPS on your other site?

C'mon, it shouldn't be so hard to pass four values to four parameters. You have four parameters: filename fsize ftype usid Now you need to pass exactly one value to each of those parameters. You're still trying to access your weird “:0” parameter which you've just deleted.

There is no second function. That's what I'm trying to tell you the whole time. There is one event handler which takes care of the animation depending on the current state of the element. The current state of the object can be stored in a variable or a data attribute or simply inferred from the style. If the element is closed, the event handler opens it. If it is open, the event handler closes it. There's absolutely no reason for constantly replacing the event handler with another function when you can simply use a single function.

I find it funny that everybody feverishly posts all kinds of suggestions when it's not even clear how the query looks like. Maybe we should take care of the basics before starting the beautification. As long as there's no proper join between the category table and the specs table (those are two separate tables, right?), all the advice regarding HTML is rather silly.

So what's the new error? Is the error reporting turned on? Are you sure the webserver has all required permissions to access the folder and files? This is one of those “arguments” which just don't make sense. So you're saying you're unable or unwilling to protect the simple parts of the program, but at the same time you write perfectly secure code when it comes to much more complicated aspects like authentication? No offense, but that's hard to believe. Anyway, if you think that saving 5 minutes of work is worth the risk, go ahead.

So? How the animation looks like is completely irrelevant. The point is that you use one event handler which takes care of the element.