Jacques1

Why checking for submit button names is a bad idea.

I'm pretty sure I've said this is programming issue, not a problem of PHP. If everybody simply used $_SERVER['REQUEST_METHOD'], we wouldn't have to worry about submit button names at all. No language can read your mind. It's the programmer's job to make the code robust against errors.

None of this has anything to do with security. The point is that the submit button is just a GUI element which should have no effect on the data processing. When your entire program breaks down just because you got the name of a button wrong, that's obviously a poor approach. The point is that print_r (or better: var_dump) is only useful when you actually get interesting information from it. Dumping $_POST tells you that the “BOGUS” selection gives you the string “BOGUS” -- well, I guess you knew that already. But dumping the in_array result, for example, would have immediately told you that there's something wrong. What is PHP supposed to report? You're checking whether there's a “Submit” parameter, and PHP tells you that there isn't.

It doesn't. The data which the XML version stores in attributes is simply stored in JSON objects.

Your submit button is called “submit”, but you're checking for “Submit”, so the code isn't even executed. Which again proves that making your entire program dependent on some silly submit button is an awful idea. I know PHP people love to do it, but that doesn't mean it makes sense. You should check for the request method, not the name of a button. if ($_SERVER['REQUEST_METHOD'] == 'POST') { } You should also use better places for your var_dump().

Is it really so hard to understand that I need facts, not speculations about how “clearing memory” will solve everything? What am I supposed to do with half of the code and the statement that you've done “hundreds of var_dumps”? As long as you don't post them, that tells me exactly nothing. As long as you don't provide any meaningful information, all I can tell you is that you neither understand JavaScript nor PHP very well. The whole point of Ajax is that it's asynchronous (that's what the “A” stands for), but you halt the entire page to make a synchronous request and write the data to some variable in the outer scope (which may very well mess up existing data). JavaScript doesn't work like this. It uses nested callbacks or Deferreds to execute code after an event has happened. The PHP code is also wide open to SQL injection attacks.

I'm afraid none of us has the advanced mind reading skills required to answer the question in its current form. HTTP requests don't magically influence each other. If the first request causes problems with the second, that's because there's something wrong with your code (or you've found a bug in the browser or PHP, but this is a lot less likely). If you want help with the debugging, we need to actually see that code and get a detailed description of what happens when. The developer tools of your browser and a few var_dump() calls will give you that information.

Reducing a problem is great, but when you also strip out all the parts which are required to prevent errors, you've effectively created a second problem. So I suggest you start over, this time with a correctly(!) written minimal example. If there's any chance you can switch to PDO, do it now and forget about mysqli altogether. mysqli is a hard-core low-level interface for very experienced programmers who love to study the manual and make sure every single line of their code is perfect. Let's be honest: You aren't that kind of guy. PDO is a much more programmer-friendly option which you can learn fairly quickly. Forget about escaping and use prepared statements instead. Contrary to popular belief, this isn't "just" a matter of security. The goal of prepared statements is to prevent the input from fucking up the query, regardless of whether that input comes from an evil attacker or just happens to contain characters which cause syntax problems (like "O'Reilly" in a single-quoted string). Set up proper error handling and reporting. Both PDO and mysqli support exceptions which are automatically triggered in case of an error, so you can get rid of the cumbersome (and incorrect) die(error_message) stuff. Write proper SQL queries. No lazy shortcuts. Chances are this will already fix your problem. If it doesn't, post the new code together with the full exception message.

Yeah. Do you understand the solution now?

Use a proper e-mail address validator instead of trying to invent your own. The regex doesn't even come close to what an address can look like. Besides that, none of us is a mind reader. If you want help, we need concrete information. Does the address get submitted at all? What does it look like?

If you immediately give up as soon as you run into a tiny problem or somebody disagrees with you, I'm afraid your career as a programmer will be a short one.

This is a hack specifically for MySQL to work around the lack of window functions. Since MariaDB and almost all other database systems don't have this problem, the hack makes no sense here. The only reasons why you would want this is to be able to downgrade to MySQL. I strongly recommend against that. MySQL is so far behind now that you should generally avoid it.

MariaDB has window functions like ROW_NUMBER().

I'm not talking about your forms. I'm talking about all method(s) which trigger mail submission, regardless of whether you've intended that or not. If merely refreshing the page immediately triggers a new mail, then you do use GET, because POST requests are protected against accidental resubmission. You would have gotten a warning like this: If you click on “Resend”, well, then you'll obviously send another mail. Long story short: The mail code must be explicitly restricted to POST requests by checking $_SERVER['REQUEST_METHOD']. Then use P/R/G to fix the remaining usability problems. <?php // this part of the code is only executed on POST requests if ($_SERVER['REQUEST_METHOD'] == 'POST') { // this is where the mail code goes // if everything was successful, do a redirect header('Location: http://example.com'); exit; } // the remaining code is executed on each request (this is where you render the page)

Don't use GET requests to trigger e-mails. Use POST and then redirect to another page (see the Post/Redirect/Get Pattern). GET requests are purely for getting content (hence the name). They must not have any side effects.

I know that. Now read my reply and think about the two options I've provided.

This isn't the We-do-your-work-for-free forum. You have two options here: You can hire a programmer who helps you set up your WordPress. This will probably cost money, there's no guarantee that it will be successful, and you'll have to be extra careful not to hand out any sensitive information. Or you can explain what you've tried and then ask specific questions which a generic WordPress programmer may be able to answer in this forum.

Since you're now juggling with three or four different versions and no longer seem to know what those scripts even contain (you claim that the older versions have no prepared statements, but all scripts do), I suggest you stop it, move all current code outside of the document root and start over with an empty directory. We cannot debug a moving target where you're constantly coming up with new _edited and _edited_edited_edited versions. When you have the empty directory, create a minimal example of a working database connection with a proper error configuration. That is, invalid prepared statements must trigger an exception. I strongly recommend you give up mysqli and switch to the much more programmer-friendly PDO. But if you think it's too late now, well, then you're stuck with mysqli. Once again: I want a single script with a database connection and an invalid prepared statement which triggers an exception. When this works, then we can talk about more complex code.

Sending the user to an error page where they have to manually go back and possibly lose all input doesn't sound particularly user-friendly. The standard approach is to send the data to the script itself (leave out the action attribute altogether) and stay there until all problems have been resolved. Then you can redirect the user to a success page with a Location header. An error page only makes sense as a global webserver setting for the (hopefully rare) case that there's a server-side issue.

So how does the calculation work exactly? You start with a base price, and each defect reduces it by 5.00? Then simply count the “No” selections. price = base_price − defect_count × 5.00 Note that with some of your example data, the result will be 0.00 if all selections are “No”.

What is a “custom page”? Why is footer-contact.php not a “custom page”? If you want to send data to an e-mail address, well, then you'll need an e-mail.

It's a shell script. Not sure what's so confusing about that. OP: What do you need the newline sequences for? The Bash echo already terminates each string with a newline. However, PHP scripts by default output HTML, and an ASCII newline is not an HTML newline. Either change the content type of the HTTP response to text/plain or use a <pre> element or convert the newlines to <br> elements.

I have absolutely no idea what you're doing there. Are you manually going through all 32 possible cases?

The code lets anybody search the entire disk for documents, including the ones which you definitely don't want to see on the Internet. That's not very clever. Even if nobody cares about the website, they will care about major data leaks. So don't be naive. Inserting raw user input into file paths is the last thing you should do. If there aren't too many files, just iterate over all documents in the specific subfolders (with a fixed pattern) and compare the file names with the user-provided search term. This also fixes the problem of case sensitivity, because you can use any comparison method you want.

Are you waiting for my permission? Just do it. PHP will tell you when it's wrong. The first statement is broken. You aren't creating a prepared statement at all, then you try to bind values to the nonexistent $stmt variable, and then you suddenly decide to make a plain query instead. This goes back to what I said earlier: Learn PDO. Don't just copy and paste random code snippets you found somewhere.