Jacques1

Proper English sentences would also help a lot. This isn't WhatsApp.

If you see all output at once, then your PHP or your webserver perform buffering. Turn it off (or flush the buffer), and you'll get the output immediately. Put ob_flush() before the flush() in case PHP is holding the output back. Then look up the buffering directive for your specific Apache/PHP module if necessary. The workflow is wrong, though: You do a plain upload (no magic here) and get back an ID. Then you either pass the ID to the processing script and get the progress with server-sent events. Or you do your polling thing where the file is processed by a cronjob which stores the status in a database, and the client keeps asking for the current progress.

The response doesn't have to be one fixed block of data like in classical web applications. It can also be a stream, which allows the server to send updates to the client without having to wait for the next request. Compared to polling, this is simpler, quicker (there are no unnecessary delays) and more efficient in terms of traffic. Client-side JavaScript code var evtSource = new EventSource("process.php"); evtSource.addEventListener("progress", function (event) { var eventData = JSON.parse(event.data); console.log("Processing: " + eventData.percentage + "%"); }); Server-side PHP code <?php header("Content-Type: text/event-stream"); function send_event($event, $data) { if (!preg_match('/\\A\\w+\\z/', $event)) { throw new InvalidArgumentException('Invalid event name: '.$event); } echo "event: $event\n", "data:".json_encode($data)."\n\n"; flush(); } for ($i = 0; $i <= 100; $i++) { send_event('progress', ['percentage' => $i]); sleep(1); }

The error messages should just be passed to the template engine (or the lower part of the script) for rendering, so the validation procedure is done at this point. At most, you'd set the response code. Also note that the above is meant for small applications. In more complex systems, you'll want a declarative approach where you only define the requirements and leave the actual validation to the framework/library. As in: “The e-mail is required, must match the e-mail pattern, is between m and n characters long ...”. Checking the requirements and displaying sensible errors is then done automatically.

Several things: Strike strip_tags() and stripslashes() from your memory. Both functions are completely useless and will actually mangle the user input so that you end up with garbage data. It's great that you're appearently trying to make your code secure, but security techniques must be understood and carefully chosen for the specific context. If you just throw all kinds of random functions at the input, that's counter-productive. Don't repeat yourself. Writing down the same thing over and over again may be a great typing exercise, but it has very little to do with programming. When you encounter a repetitive task, you should ask yourself two things: Do I even need this? And if that's the case, how can I implement it in a smart way with abstraction and loops? In your case, you don't need this. Copying every POST paramater into a local variable is nonsensical. Validate user input. Don't just assume that all expected parameters are there. A smarter approach: <?php // first declare all POST parameters we expect to get from the user const REQUIRED_PARAMETERS = [ 'username', 'password', 'password_confirm', // ... you get the idea ]; // collect all error messages $errors = []; // Did we receive a POST request? if ($_SERVER['REQUEST_METHOD'] == 'POST') { /* * Check if all required parameters are present; note that I'm using a loop rather than writing down the same * statement over and over again */ foreach (REQUIRED_PARAMETERS as $required_param) { if (!isset($_POST[$required_param])) { $errors[] = 'Missing parameter: '.$required_param; } } // TODO: Further validation if necessary if (!$errors) { // *Now* you can assume that the input is correct and start the actual processing } } ?> <!-- TODO: If there are error messages, display them on the page -->

If you don't need compatibility with Internet Explorer, you can use Server-sent Events. Then you can take the long-running processing script you already have and simply make it send regular updates to the client (e. g. the percentage of completion).

I have no idea what you've just said.

How about The static keyword Note: Static declarations are resolved in compile-time. [...] From PHP 5.6 you can assign values to these variables which are the result of expressions, but you can't use any function here, what will cause a parse error. It took me 10 seconds to find that. If you're less experienced with Google or the structure of the manual, it might take you 30 seconds. My point is that you need to learn how to do your own research.

A uniqueness constraint can span more than one column, if that's what you mean. CREATE TABLE ... ( ... UNIQUE (col_1, col_2, ..., col_n) ); Then only the combinations of the columns have to be unique, not an individual column.

If only there was some kind of language reference where we could look that up. Like a ... manual.

Who said anything about SQL skills? I'm talking specifically about your problem. If you missed that, you might want to read the post again.

The error messages look pretty clear to me: When a function expects 2 parameters, you can't provide less than 2. It seems you're trying to translate old mysql_* function calls to myqli by appending the letter “i” everywhere. This doesn't work. Even worse: Your code is wide open to SQL injection attacks, because you just insert all variables straight into the queries. Don't do that. Use prepared statements with parameters. Actually, I would recommend you forget about mysqli (you don't know it anyway) and learn PDO instead. PDO is much more versatile and user-friendly.

This is BS, and it's sad that you obviously haven't learned anything in the last months despite getting a lot of good advice. First off: If you have trouble with collisions, there's something wrong with your generator or the length of the generated IDs. Proper random IDs (e. g. 128 bits from a device like /dev/urandom) do not collide. In fact, they're commonly used as globally(!) unique IDs. Secondly, stop trying to reinvent the squared wheel. You've been told two times already to use uniqueness constraints, yet you're still fumbling with your transactions. If this is an educational project, I'm afraid you've missed the educational part.

Join the original table with the result set of your current query. SELECT contest.playerref, contest_stats.games_played FROM contest JOIN ( SELECT playerref, COUNT(*) AS games_played FROM contest GROUP BY playerref ) AS contest_stats USING (playerref) ; Proper database systems like PostgreSQL have window functions for that purpose, but MySQL doesn't and probably never will.

I've just told you how to investigate the problem: If the array index is invalid, log both the ID and the session content. None of us is psychic, so if you expected us to just pull out the magic bugfix, that won't happen. Especially when there's a problem with the whole application.

Which information? You can delete your profile data, replace your e-mail address and remove all private messages by yourself. I'm not sure if the admins can do much more than that.

Besides the (potential) session issues, there's clearly something wrong with both your PHP configuration and your validation. Users should never see internal PHP errors. Turn those off and enable logging instead. Also, input must always be validated. If there's a problem, you display a meaningful error message (e. g. “Invalid questionaire ID”) and possibly log additional information for debugging (like the invalid ID and the current session content). So fix this first. Does the ID parameter even make sense? You said you have one questionaire, so why do you need the user to provide the ID all the time?

There are plenty of input fields which are obviously not meant to be sent. I'd be careful with that.

Let's look at this line: data: {"amount": $('#x_my_amount').val()}, This is what gets sent to the server. I'm sure you can figure out the rest.

The approach is weird, to say the least. First you check if the person was born before today (shouldn't that almost always be the case?). Then you travel back into the year of the birth and calculate the difference between that past date and the birth date. What is this supposed to tell you? The difference can be negative. It can also be one day off compared to the actual difference in this year due to leap years. Long story short, it's not very useful. When you want to calculate the days to your next birthday, you care about this year and possibly the next year. Not 1985. There are two cases: Your birth day in this year (i. e. 2016-04-11) is either today or after today. Then you simply calculate the difference between that day and today. The birth day in this year was before today. Then you calculate the difference between the birth day in the next year (2017-04-11) and today. This yields 153 days. I strongly recommend you always solve the problem on paper before typing anything on the keyboard. When you simultaneously struggle with the programming language and the problem itself, you're unlikely to get the correct result. You also need to check your understanding of basic control structures. The bizarre switch-statement-acting-as-an-if-statement is not really how PHP (or any language) works.

So this a security question? A PHP process on some server has no access to your system. Calling exec() only executes programs on the server. It doesn't magically start programs on other machines. Compromising your system through a website requires either a browser vulnerability or a network-related vulnerability. Neither has anything to do with PHP.

Um, what? What you describe sounds an awful lot like malware, so it might be helpful to explain why you need this strange setup. What is this executable? Why should it be started from a website? A website can't just run executables on arbitrary PCs. That would be horrible.

Because you're not supposed to hijack threads of other users or dig out discussions from 2015. Create your own thread. It's not that hard. You can still link to this thread if you feel it's relevant. Got it now?

This is very hard to believe. The application must be truly fucked up to mangle the literal input “đ” into a Unicode character. And it must be even more fucked up to not accept the original character. Your claim that some characters work while other don't again indicates a data problem. I strongly recommend you check specific data records directly in the database (not with PHP). That is, search for “đ” with your web form, then look up the found rows directly in the database. If you can definitely confirm that the record is found despite not containing “đ”, we need to see your code. Is JavaScript involved?

Yes, potentially. It doesn't matter. I would never even try to distinguish between “safe” and “unsafe” values: Even “safe” values can screw up the application (it's not just about security). Just because we cannot think of an exploit doesn't mean the input is in fact safe. I've seen many examples where experienced programmers were absolutely sure that an exploit is impossible, and then they turned out to be wrong (servers are sometimes misconfigured, PHP sometimes has bugs, and we're fallible too). Constantly having to decide whether or not you should escape a value is extremely error-prone by itself. Code changes all the time. Maybe the input is safe now, but that may no longer be true after the next revision. And I'm pretty sure you don't scan your entire application whenever you make a small change, just to be sure that your assumptions still hold. I think the only valid approach is to escape every value except the ones that are supposed to be HTML fragments. This is classical whitelisting. What you've proposed is essentially blacklisting. No. I would use relative URLs: ?p=contact As in <form action="?p=contact" method="post"> Even better would be properly rewritten URLs where you don't have to add parameters all the time, e. g. /contact -> index.php?p=contact