Jacques1

The idea of “sanitizing” user input is bullshit and downright harmful. Input by itself doesn't do anything. It's just data. The problem is that many programmers fail to use the data properly. For example, if you naively insert the raw user input into a query string, then you have an SQL injection vulnerability. This is not a problem of “evil input”. The user hasn't done anything but submit a bunch of text. It's your fault that you have inserted this data into a query instead of using a prepared statement. So, no, you don't need to validate the data. You have to treat it correctly and not do any strange things with it. This actually applies to all data, not just user input. To stick to the previous example: If you need to pass values to a query, you always use a prepared statement, regardless of where the values come from. Treating validation as a security feature is actually a huge misunderstanding and can lead to serious vulnerabilities. Just because the input is formally valid doesn't mean it's harmless in every possible context. For example, a perfectly valid e-mail address may very well carry SQL fragments for an injection attack. The sole purpose of data validation is to ensure formally valid data. If you need that, go ahead. But this is not a security feature.

Do you guys seriously try to manually assemble a multipart message? There are libraries for mailing!

To be honest, I have no idea what you mean. You want people to include your PHP script? How is that supposed to work? You realize that the script would run on the client's machine? Since they don't have your database, all it would do is crash. Besides that, running PHP code from some remote server is pretty much the last thing a sane administrator wants. Who knows what that script does? What if your server gets compromised and starts distributing malicious scripts? So, no, this is not an option. It also makes no sense to push the data collecting logic to the client. They don't care how the data is collected. All they're interested in is the data. APIs are typically based on the HTTP protocol just like web pages. The difference is that APIs are machine-friendly, while web pages are aimed at humans. A web page will deliver fancy GUIs based on HTML and CSS. On the other hand, an API will serve the data in an easy-to-parse format. JSON is fairly popular, but you might as well use XML or any other format you think makes sense.

Bollocks. Nano-optimizations like that are just plain silly and make the code absolutely unreadable. As soon as you work in a team or publish the code, people will hate you for “great ideas” like that. If you have trouble with the performance of your application, it's not because of strlen(). The issue is that you haven't said anything about your problem. No, “doesn't work” is not a sufficient error description.

I know, it's only a school project, you'll add security later etc. Leaving all that aside: You cannot use this code on the Internet. If you want your application to survive more than just a few minutes, you need to fix your queries, hash the passwords properly and not send them around in e-mails.

I think you misunderstand the purpose of this forum. This is no “code repair service” where you leave your broken application and come back later to pick up the fixed version. You fix the code. We might be able to help you with that, but only if you actually tell us what's wrong. No, “doesn't work” is not a sufficient problem description. Since we're not sitting in front of your PC, you need to actually describe what happens when you execute the script and why you think that's wrong. In any case, that part of the code doesn't look good: if(unfavorite="1" where id='".$id."') { "delete from favoritedeals WHERE id= '".$id."'"; } What is that weird SQL fragment in the condition? And the DELETE query below never gets executed. Besides that, your code is wide open to SQL injection attacks. Since you happily drop the raw user input into your query strings, you allow anybody to manipulate the queries and access arbitrary data. The mysql_* functions you're using are also obsolete since more than 10 years and will be removed in one of the next PHP releases. Nowadays, we use PDO. The great thing about PDO is that it supports prepared statements to securely pass values to queries. So this can fix your injection problem as well.

Never store passwords as plaintext or even send them around by e-mail. The passwords are highly sensitive data and could be used on other websites as well, which means it's your duty to protect them with state-of-the-art security. If you're unable or unwilling to do that, you should remove the registration feature. Since you happily drop the URL parameters into your query strings, you actually allow anybody to write their own queries and, for example, fetch all plaintext passwords. You might as well publish the database credentials. I strongly recommend that you learn the basics of web security and database access before you even think about storing user data. I'm not saying this to put you down, but leaking the data of other people is simply unacceptable.

Where the data comes from is irrelevant for this problem. The point is that you do all your link logic after the user has made their choice. The user only tells you “I want used cars” or “I want new cars”. Based on that decision, you then fetch the links from an array, a database or whatever.

What a mess. You can't have single-quoted indexes in double quoted strings. You either need to leave out the single quotes altogether or use the curly brace syntax: <?php $some_array = array( 'foo' => 42, ); // This is OK echo "The number is $some_array[foo]"; // This is also fine echo "The number is {$some_array['foo']}"; // This is wrong // echo "The number is $some_array['foo']";

This makes no sense, and we can't really help you based on a few column names and a vague description. What do the rows in “table” (I hope that's not really the name) represent? How would an example row look like? What would the expected result look like? Also note that storing Unix timestamps is bad idea. MySQL has actual data types for dates and timestamps: The DATE, DATETIME and TIMESTAMP types. Use them.

There is nothing to split. As I've already tried to explain, you only need a single value for the radio buttons. In your example, the value is either “new” for new cars or “used” for used cars. After you've received the submitted data, you're free to create your links. But it's absolutely pointless to have the links as form values.

I don't think you've understood my reply. I asked the OP why he/she gets tons of HTML entities as the input instead of the characters themselves. That's a rather odd way of dealing with UTF-8 data. No, I do not have a problem with non-latin characters.

There absolutely no reason for putting this data into the form. The purpose of the form is to let the user choose a filter. So in your case, the radio button values would be “new” and “used”. What you do with the user choice is a completely different story. In the processing script of the form, you can create as many links as you want. But you don't do this in the form.

This forum is for helping people with their code, not writing it for them. If you need a programmer to do the work for you, hire one.

The whole problem still doesn't make a lot of sense. You have a text field, which means the user can enter anything they want. How do you know they will enter exactly three brands? How do you know you can just append “.com” and get a valid URL? And why do you predefine the favorite brands?

It makes no sense to fetch the current date in PHP and insert it into the query. MySQL is very well able to do that itself: Date and Time functions in MySQL What you want is CURRENT_DATE().

Why do you have those weird HTML entities at all? Where do they come from? As a workaround, you would use html_entity_decode(). But the question remains.

The $_SERVER['SCRIPT_NAME'] variable contains the filename of the script, nothing else. The parameters after the question mark are not included. I'm not really sure why you're using this strpos thing, anyway. You obviously know the $_GET array, so why not use that? if (isset($_GET['qtitle'])) { echo $_GET['qtitle']; } else { echo "You haven't added any questions yet."; }

Well, I'm not sitting next to you, so you'll have to be a bit more concrete. What does the src attribute look like? Is this what you expected? Why does it not point to an existing image?

Dumping unescaped values into your HTML document is a very bad idea. Dumping them into unquoted attributes is even worse. The broken images are actually a rather harmless symptom, you can easily run into much severe bugs or even security vulnerabilities. Always escape input and quote attributes. So in your case, you want something like this: <?php echo '<img src="'.html_escape($row['image_th']).'" width="200">'; function html_escape($raw_input) { // If you're not using UTF-8 as the document encoding, adjust this accordingly. return htmlspecialchars($raw_input, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'); }

You simply use the activity IDs as the values of the select element. When the user chooses an activity, the corresponding ID gets submitted. On the target page, you can then fetch any activity data you want by making a query with a WHERE clause.

What's the concrete issue? Understanding how forms in general work? Using the submitted value to look up all the other data? Something else? I can't help you based on such a vague question.

You got the indexes wrong. Looking at your debugging code, it seems you want to search for $_SESSION['leitner']['boxes'][$box + 1]. But you're actually searching for $_SESSION['leitner']['boxes'][$box - 1]. Note the third index.

I have absolutely no idea what you're trying to do and why. On the one hand, you're asking about multiple values. Then you're suddenly talking about multiple names (whatever that means). And what's the whole purpose of this strange exercise?

And now it might be a good idea to read my reply as well.