Jacques1

I understand you want to get your task done. The problem, as I already told you, is that you struggle with PHP at a much more fundamental level: syntax, variables, basic form processing, database interaction, security and probably more. This needs to be resolved before we can even begin to discuss your problem, and I don't think anybody here has the time to give you personal lessons. I know it's tempting to just copy and paste random code from the Internet and then go to an online community to fix and adjust it. But there's a limit to this approach. You'll need at least a basic understanding of PHP. If you don't speak Japanese at all, you wouldn't expect people to help you write an epic novel in Japanese, right?

Oh my. Before you do anything, I suggest you start with a beginner's course for PHP (like the one on CodeAcademy). As long as you struggle with even the most syntax rules, it's pointless to try a complex project. Learn the basics of PHP, learn how to connect to a database system in the 21st century, then come back.

No, there is no way to get the client's timezone with PHP. As you probably know, PHP runs on the server, and the HTTP requests sent by the clients don't contain any timezone information. What you can do is try to get the timezone with JavaScript or make the user explicitly select their timezone. You can also use the IP address and a geolocation database to make an educated guess (but you still need a way for the user to correct the information).

Reading the replies also helps. As I've already told you, programming by trial-and-error doesn't work. Remove the parts which aren't relevant for the problem (like the mail stuff), learn how to use var_dump() and then analyze the problem systematically.

“vehicles” isn't the same as “vehicle”. Yes, you have to be exact. In any case, it's time for you to learn basic debugging steps. Forget about the e-mails. Right now, you cannot even assemble the message correctly, so it's nonsensical to add complex mail sending logic which may introduce even more errors. Remove the mail() call for now. Learn how to inspect variables with var_dump(). For example, var_dump($_POST) will tell you exactly what the $_POST array contains (and what it doesn't contain). When you're more experienced, check out professional debuggers like XDebug. This will save you a lot of time.

The comment is outdated, and it's not true that mysqli requires messy code for a dynamic number of parameters. PHP 5.6 introduced the splat operator which makes this trivial to implement: $searchTerms = explode(' ', $_POST['strings']); $searchStmt = $databaseConnection->prepare(' SELECT * -- list the specific columns! FROM core_table WHERE item_name IN (NULL '.str_repeat(', ?', count($searchTerms)).') '); $searchStmt->bind_param(str_repeat('s', count($searchTerms)), ...$searchTerms); $searchStmt->execute(); Nonetheless, PDO is the better extension.

There is nothing to be shown. You create as many parameters as you need, you pass the array to execute(), and that's it. $searchTerms = explode(' ', $_POST['strings']); $searchStmt = $databaseConnection->prepare(' SELECT * -- list the specific columns! FROM core_table WHERE item_name IN (NULL '.str_repeat(', ?', count($searchTerms)).') '); $searchStmt->execute($searchTerms);

Choosing the parameter type based on the PHP type doesn't make sense, because there is no simple one-to-one mapping. For example, large MySQL integers don't fit into PHP integers and must be stored in strings instead. So there are two options: Either you explicitly provide the types together with the input data. Or you cast the parameters in the query. ... CAST(:param AS INT) ...

Do you not understand that there's a difference between the number 80 and the string “$80”? Can't you see the dollar sign? This will fudge up any calculations, because PHP cannot convert that into a meaningful number (so it converts it to 0). You need to repair your database. The price must be stored in a numeric column (e. g. DECIMAL) without any currency symbols. If the currency is always the same, you don't need to store it at all. If there are different currencies, I recommend you store them in an additional column and then add the currency symbol in the application.

If the data comes from a third party (which is pure speculation), then you sanitize it before putting it into the database. Even the weakest programming language is far better at string operations than any MySQL hack. In any case, I'd be careful with literal answers. Users often fail to show their actual problem and only post random ideas they've come up with. Implementing those ideas may not solve the problem at all.

Where do those brackets even come from? When people need strange string manipulation hacks for their data, there's usually something wrong.

Then what is even the problem? Forget about this crazy output buffering stuff and just use the variables: $percentage = 0.1; $result = (1.0 - $percentage) * $row_product["rrp"]; echo 'The result is '.$result.'<br>'; This is basic programming. Your math also seems to be off. When you calculate $result - $value, you get a negative value. I'm fairly sure you want the opposite direction, i. e. 90% of the original value.

MySQL doesn't have CHECK constraints. You can create them, but they're completely ignored.

First, the code doesn't make any sense. Why on earth do you echo the content of a variable and capture the output in another variable? Why not just use the first variable? Secondly, you need to learn how to do basic debugging. Obviously your $row_product doesn't contain the data you think it does. So check how it actually looks like: var_dump($row_product);

And you tell us that now? Yeah, so much for the super-secure public-key handshake kung fu. This project is BS, and as a developer, you should be able to see through the fancy buzzwords. Once again: This is nonsense. What you're saying doesn't even make sense. Use an API key. If the client doesn't want HTTPS, they're obviously willing to take certain risks. So be it. Inventing your own nonsense protocol isn't going to help anybody. Do what you can and be honest about it.