Jacques1

So, what's the problem? Or is everything fine now?

Are you sure the filename has an .htm or .html extension?

What kind of trouble? Does your PC catch fire when you run the script? Do you get an error message? A specific unexpected result for a specific input? I know this is hard to understand, but we're not sitting in front of your screen, and we cannot read your mind. All you've provided is a wall of code and the vague information that you think there's something wrong with it. What are we supposed to do now? Be specific.

Don't hijack threads of other users, create your own. And the chance of somebody helping you with “the problem” is close to zero if you won't even tell what “the problem” is.

Cool.

OK, and how does the first HTML fragment “not work”? What makes you think that?

Post the code as text, not as a bunch of short-lived screenshots hosted on some external site. Your previous thread is now completely worthless, because your stupid image hoster has taken the picture offline.

We don't need your speculations. We need you to var_dump() the three variables and post the output. Why is this so hard for you? If you cannot do this, then we cannot help you.

The error doesn't disappear, only the message. That's like burying your head in the sand. You're passing 0 to what parameter? The limit? The offset? The user ID?

What is the exact content of the variables you pass to the parameters? Post a var_dump() of each. Are you using emulated prepared statements?

mysqld_stmt_execute() is an internal MySQL function. You cannot “remove” it.

Is the MySQL version up to date?

The logic already makes no sense, because your second “filter” always overrides the first one. Even if the second filter isn't used at all, the query from the first one will be overriden with the default query. There's also a lot of duplicate code (why would you write three queries for three colors?). I think you should plan the code before you start typing. To make sure we agree on the facts: There's a base query. The date “filter” affects the ORDER BY clause. The color filter affects the WHERE clause. Both filters can be selected simultaneously (at least I see no reason for preventing that). So why don't you start with a variable for the WHERE condition(s) and a variable for the ORDER BY clause? Depending on the request parameters, you change those variables. At the end, you assemble the query.

Are you volunteering to rebuild the entire Highcharts configuration structure with normalized tables and write the code for converting the two?

no type safety (unless you're using PostgreSQL which has a JSON type) race conditions due to the two-step updates (load then save) if no synchronization is used inefficiency due to the need to always load the entire document into the application

More like dedicated hardware.

The PHP manual is usually a good start, because it has plenty of examples and will warn you when a function is not recommended. There's also the online security book by Padraic Brady, but it only covers some topics (not password hashing) and isn't really meant for beginners. What's important to understand about modern password hash algorithms is that you cannot do a simple string comparison like you would with, say, MD5. The hashes are parameterized with a cost factor and a random “salt”, so to verify a password, you have to load the existing hash into the application, hash the password with the same parameters and then compare the hashes. If you use the above mentioned password hash API, the last two steps are automatically done by the password_verify() function: // create and execute prepared statement to get the user data $userStmt = $databaseConnection->prepare(' SELECT id, password FROM customer WHERE email = :email '); $userStmt->execute(['email' => $_POST['email']]); $user = $userStmt->fetch(); if ($user) { if (password_verify($_POST['password'], $user['password'])) { // Everything OK } else { // Wrong password } } else { // Wrong username } (The above code uses PDO rather than mysqli; with mysqli, it will be a more complex)

I doubt that, because database systems like MySQL cannot store true or false. So what does the variable really contain? An integer like 0 and 1? A string like “true” and “false”? Something else? If you don't know, var_dump() will tell you: var_dump($status); Post the output here. You already said that you're probably having a brainfart, so why get pissed off when somebody points out the exact problem? Asking if a condition is “less than fulfilled” is just an odd way off thinking. Nobody made fun of your programming skills.

If you use low-level PHP, you have to set the character encoding in every component that involves text. From PHP 5.6 on, a few cases can be covered with the default_charset directive, but this is still far from a universal setting and requires tight control over the environment. Tedious tasks like this are the reason why frameworks exist. For example, a template engine with auto-escaping eliminates all htmlspecialchars() calls and allows you to put boilerplate markup like the meta element into a base template.

You can literally copy and paste your code into my foreach loop. You have to add the 'ID' key to your array, though: WordPress Function Reference/wp_update_post

Leaving the JSON discussion aside: How do your users edit the configuration? Graphically? Then why don't you use the same GUI for creating/editing a chart and simply overwrite the entire configuration? Trying to update individual parts will be very tedious and undermines your initial justification for JSON. If you want fine-grained control over the configuration, JSON is not the right approach.

So what do you not like? The \u escape sequences? JSON_UNESCAPED_UNICODE However, this is an entirely unnecessary step, because JSON is just an intermediary data format. As soon as you parse it, you'll get human-readable text.

You could try to implement the functions yourself as simple wrappers for PDO. If you're lucky, you won't have to make any major changes to the application code. However, an application which appearently hasn't been touched for more than a decade may have lots of other issues. I'd be suprised if the ifx_* functions are the only fossil rotting in the code.

What? You want to use your users as laboratory rats for potentially malicious sites? Are you kidding? If you don't know if a site is trustworthy, then don't redirect to that site. What kind of application is this, anyway? You generally cannot “see what a user is doing on another site”, and with good reason. Would you want us to see your PayPal account, your e-mails, your private Facebook messages?

The query is vulnerable to SQL injection attacks. Learn how to use prepared statements. Actually, the whole approach with all those hidden fields and client-side parameters is strange. Do you want the user to set an arbitrary price? Or shouldn't the price be calculated by the server after the user has chosen a shipping option?