Jacques1

Several things:
Don't show your internal database errors to your visitors. It's very irritating for legitimate users, and it helps attackers gain information about your system. Instead, enable exceptions, so that error messages are automatically sent to the right device according to your PHP configuration (an error log in production, the developer's screen during development). Your database structure is broken. Whenever you find yourself numbering table names or columns, there's something wrong. SQL is not Excel. It's a database system with specific rules how to store data. Don't use SELECT *. Always select specific columns. Don't copy every item of the $row array into an extra variable. Just access the array items whenever you need them: $row['index_of_the_item']. You'll want a more meaningful name than $row, though. Stylistic HTML attributes like align, width, color etc. are dead since 1997. We have CSS now. If this is the entire script, you're also failing to output a complete and valid HTML document. Create a function for your database connection so that you can reuse this code in all your scripts:
 
database.php
<?php /** * Establishes a MySQL database connection using mysqli * * @param $host string the hostname or IP address of the database server (e. g. "localhost") * @param $user string the name of the database user * @param $password string the password of the database user * @param $database string the database name * @param $charset string the character encoding of the connection (e. g. "utf8) * * @return mysqli the connection * * @throws mysqli_exception if the connection failed */ function connect_to_database($host, $user, $password, $database, $charset) { // make mysqli throw an exception whenever it encounters a problem $mysqli_driver = new mysqli_driver(); $mysqli_driver->report_mode = MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT; $database_connection = mysqli_connect($host, $user, $password, $database); // specify the character encoding of the database connection $database_connection->set_charset($charset); return $database_connection; } Then create a configuration script to hold the connection parameters:
 
configuration.php
<?php const DATABASE_HOST = 'localhost'; const DATABASE_USER = '...'; const DATABASE_PASSWORD = '...'; const DATABASE_NAME = '...'; const DATABASE_ENCODING = 'utf8'; Fix your database structure. For example:
TABLES quizzes - quiz_id questions - question_id - question answers - question_id - answer - is_correct quiz_questions - quiz_id - question_id

No need to apologize. I'm simply pointing out that efficiency isn't the issue here.
 
Choose the most readable solution. If it makes sense to only fetch the title, that's perfectly valid. It doesn't matter if you need a few extra queries, because there won't be any performance difference at all.

I've already told you what to do: Put the array initialization before the loops, so that they only happen once and aren't repeated in every iteration. You want to keep the same array throughout all iterations.

The jQuery 2 and 3 branches don't support very old browsers like IE8. You have to either give up IE8 support yourself or stick with jQuery 1.

Your goals and ideas don't make any sense from a technical standpoint.
 
If you want to be sure that the eBay stock is updated during the purchase, there will be a delay for the user, even a potentially infinite delay. Network operations can be slow. Network operations can fail (yes, this happens). The only way would be to wait for the response indefinitely, and if there's any error, try again indefinitely. This is obviously unrealistic. And you may still end up selling out-of-stock items: What if somebody purchases the last item on eBay right after your user has clicked on the “order” button and before you make your API calls?
 
Note that this is also a legal question, so if you're a newbie, you definitely shouldn't invent your own processes. Either find a widely accepted standard solution. Or discuss this with an e-commerce expert. The shops I worked on had a non-binding order confirmation on the website and a separate binding confirmation sent by e-mail. But I'm not a lawyer, so I cannot tell you if this works in every country and in every context.

Just don't. Don't rely on languages to guess what you mean when you juggle with nonsense values, and don't try to produce results from nonsense input.
 
I know this is hard to believe for a PHP programmer, but many languages actually trigger an error when the program does weird things like trying to calculate sums of void values. You should do that too, because it's the most straightforward reaction. If you absolutely must produce a result, then return immediately after validation. No magic.

$Clue_No isn't the same as $Clue_no. PHP variables are case-sensitive.
 
If you get a proper IDE, it will actually point out trivial mistakes like this and save you a lot of time.
 
Also note that your default case will trigger an error when you try to access $result, because there won't be such variable. You should fix your logic. Personally, I would avoid magic numbers and switch statements at all costs, because it quickly turns the code into an unreadable mess.

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); }

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.

Erase the code from your disk, forget what you think you know about PHP, start from scratch
The Codeacademy PHP course (learning the basics of PHP) Exploits of a Mom (why security matters) (The only proper) PDO tutorial (how to communicate with a MySQL database in the 21st century) The PHP manual (lots of useful information and warnings)

Just remove the modifer.
 
The replacement operation itself looks strange, but that's another story.

Yes, that's PHP-FPM.
 
Do you have an init script for PHP-FPM? Then you simply need to use that instead of the nginx one after you've updated the PHP configuration:
/etc/init.d/php-fpm restart (the script could be named differently)
 
There are also plenty of init scripts on the Internet.

How is the second query even possible? Are you storing your passwords as plaintext?

A SHA-2 hash is not a SHA-2 HMAC. As I already said above, you simply create an extra column for the HMAC of the e-mail address and make it UNIQUE. Whenever you want to add a new address, you calculate the HMAC with PHP and try to insert the address together with the HMAC. If the address already exists, the HMAC will be identitical to an existing value and violate the UNIQUE constraint. Otherwise the query will succeed, and you know that the address is indeed unique.
 
It's really very simple once you understand the idea.
<?php class HMAC { /** * @var the underlying algorithm for the HMAC */ const ALGO = 'sha256'; /** * @var the length of the HMAC key in bytes */ const KEY_LENGTH = 32; /** * @var string the HMAC key */ protected $key; /** * HMAC constructor. * * @param string $key the HMAC key */ public function __construct($key) { if (!is_string($key)) { throw new InvalidArgumentException('Invalid key type. Expected a string.'); } if (strlen($key) != static::KEY_LENGTH) { throw new InvalidArgumentException('Invalid key length. Expected '.static::KEY_LENGTH.' bytes.'); } $this->key = $key; } /** * Calculates the HMAC of a message * * @param string $message the message * * @return string the resulting HMAC */ public function calculate($message) { if (!is_string($message)) { throw new InvalidArgumentException('Invalid message type. Expected a string.'); } return hash_hmac(static::ALGO, $message, $this->key); } /** * Verifies the integrity of a message with a known HMAC. * * @param string $message the message to be verified * @param string $hmac the known HMAC * * @return bool whether the HMAC of the message matches the known HMAC */ public function verify($message, $hmac) { if (!is_string($message)) { throw new InvalidArgumentException('Invalid message type. Expected a string.'); } if (!is_string($hmac)) { throw new InvalidArgumentException('Invalid HMAC type. Expected a string.'); } return hash_equals($this->calculate($message), $hmac); } } <?php $key = hex2bin('8311f033e7235286f5d9b17f2e83366989c3f12b414dc15348dbed2aaa102b2d'); // note binary key $hMAC = new HMAC($key); $email = 'foo@example.com'; $emailHMAC = $hMAC->calculate($email); // insert $email with $emailHMAC

The code you've copied and pasted checks for PHP 4.3.0 which was released 14(!) years ago and doesn't even work for mysqli which was released 12 years ago. So wherever you got this from, it's literally ancient.
 
I understand that you're still learning, and that's exactly what this forum is for. What I'm trying to get across is that programming is more than “somehow making things work”. Sure, you can assemble your programs from 14-year-old code snippets you found somewhere on the interwebs. And you might even get a result in the sense that you see rendered HTML on the screen. But that's not really programming.
 
Modern PHP is actually a decent language which allows you to write secure and compact code, but so many people learning PHP (not just you) seem to be stuck in early 2000. That's why I'm trying to promote the PHP of 2016.

And the $order_complete variable comes from where? You realize that variables only exist while the script is running, right? When the page is reloaded, the variables from the previous run are long dead.
 
The overall approach seems very odd, so it might be a good idea to start from scratch:
Braintree appearently uses POST requests to confirm orders. So you need a script which reacts specifically to POST requests (see $_SERVER['REQUEST_METHOD']), not plain GET requests. When you receive a (positive) confirmation, you send an e-mail. But don't use the strange approach of including some other script which then sends the e-mail. This is extremely confusing, and I bet that requesting the script directly in the browser causes trouble. If you don't want to have the e-mail code directly in the main script (which makes sense), define a function or method and then call it in the main script. After the confirmation has been processed, you redirect the client to a status page which merely displays the success/failure message. Since the status page doesn't do anything, the client can reload it as often as they want. See the PRG Pattern for a more detailed explanation.

When you set custom HTTP headers, the client has to preflight to determine whether the actual request will be valid. This is the OPTIONS request you're seeing in the log. When you respond with a 401 code, the client assumes that the test has failed and will not send the actual request.
 
To fix the problem, exclude OPTIONS requests from the header check so that the client will get a 200 response.

CSP rules are defined with an actual HTTP header, not a meta element. You either make your webserver add the header, or you use the header() function in PHP.

Don't use the e-mail address as an identifier. Use an additional public username.
 
Misusing e-mail addresses as usernames is generally a bad approach, because it's almost impossible to hide them even from the public interface. For example, if I want to check if foo@example.com is registered, I can simply measure the time (as the slow bcrypt check only takes place when the address exists).

$database_connection->exec("
SELECT
'FIELD_1'
-- ...
UNION ALL
SELECT
*
FROM
mydatabasetable
INTO
OUTFILE 'E:/Data/exports/DailyExport/myoutputfile".date('Ymd').".csv'
FIELDS
TERMINATED BY ',' ENCLOSED BY ''''
LINES
TERMINATED BY '\r\n'
");

mysqli::set_charset()
 
Also make sure that your HTML documents are declared as UTF-8 (with a Content-Type: text/html;charset=UTF-8 HTTP header and a <meta charset="UTF-8"> element).

You can't override a method and then change the signature entirely. This wouldn't make any sense, because one of the core principles of OOP is that you can substitute superclasses with subclasses. You're trying to violate this principle, because $obj->display() would work for instances of Base but not for instances of Editor.
 
What you can do of course is make the parameter optional in both classes and throw an InvalidArgumentException when null is passed to the method of Editor.
 
Or try to set up a less confusing architecture (e. g. two different methods).

First off, I would not use a global pool of IDs, because this is complex and makes it very difficult (if not impossible) to set up a proper database layout with foreign keys. Right now, your ratings don't point to any real entities, you're just storing arbitrary numbers. If I wanted to “rate” the ID −456, I could do that, which is obviously a problem.
 
A far better approach would be to have plain old per-table IDs and different tables for the different ratings. Even a single table with a type column (i. e. no referential integrity) is better.
 
If you absolutely must have global IDs, use random UUIDs (MySQL even has a function for that). Your uniqueness checks don't work.

The benefit of using composer is that you get automatic dependency management. If you rely on a phpunit.phar file, you have to manually download it on every system and make sure it's the right version.
 
To get started, you can read existing tests of (simple) GitHub projects. If you don't like the PHP-specific resources, you can also switch to Java unit tests which work very similar.

I have no idea what a “classified post” is, but if you want an actual countdown, you need JavaScript.
 
For example: Make an Ajax request, use PHP to calculate the number of seconds until the next possible submission, then start a JavaScript timer which shows and counts down those seconds. There are thousands of example scripts.