Jacques1

Yes, because there is no “calories” column in your result set. The only column is “SUM(calories)”. To get a more handy name, use an alias:
SELECT SUM(calories) AS total_calories FROM ...; Then the column is called “total_calories”.

yahoo.com does have an X-Frame-Options header. They want a User-Agent header in the request, though.

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).

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

I doubt that. The first two errors have nothing to do with VMs, they're simply the consequence of not whitelisting the reCAPTCHA inline styles and frame as explained in the documentation. You actually have no frame-src or style-src at all.
 
The last error comes from the fact that the application in the VM runs under a different domain. You need to add that domain to your site key.

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.

First off, you need to get rid of this strip_tags() nonsense. This can in fact destroy your passwords, because it blindly removes anything that looks like HTML markup.
 
The password_verify() function works like this:
if (password_verify($the_password_to_be_checked, $the_stored_password_hash)) { // correct password } else { // wrong password }

Like I said above: Use a standard format like JSON or XML. PHP already has parsers for those.
 
For example:
 
config.json
{ "name": "some_name", "description": "some description", "version": "1.0", "author": "RMorrison" } Parsing:
<?php $config_content = file_get_contents('/path/to/config.json'); $config = json_decode($config_content, true); // echo the version number for testing echo $config['version'];

The proper way is to replace mysqli with PDO. If that's not an option, get_result() is OK as a workaround. It does require the MySQL native driver, though (which isn't available on all systems).
 
 
It's theoretically possible with call_user_func_array() and an array of references, but this is really ugly.

A prepared statement doesn't have a fetch_array() method. Read the manual on how prepared statements work.
 
Actually, you don't need this at all, because you have no external input. The entire method can be boiled down to
function listMerchant() { return $this->mysqli->query('SELECT col1, col2, ... FROM core_merchant')->fetch_all(MYSQLI_BOTH); }

First, every directory and file of the application should be owned by an administrative user (like the one you use to SSH into the machine), not the webserver. The group should be the group of the webserver (usually www or www-data).
 
Appropriate permissions for read-only directories are: read+write+execute for the user, execute for group, none for the world. This means the administrative user can do anything, the group (i. e. the webserver) can only enter the directory, everybody else has no permissions at all.
 
For writable directories: read+write+execute for the user, write+execute (and possible read) for the group, none for the world.
 
The minimal permission required to use a directory is “execute”. “Read” means that the files in the directory can be listed (which is usually not necessary and may be dangerous). And “write” allows creation of new files.

The whole approach of building the table with dynamic query gymnastics is bad, so you shouldn't try to replicate this with PDO at all.
 
I know this is hard to understand, but SQL is not Excel. SQL is supposed to store and provide data, not render pretty tables. That's what your application is for.
 
So use your database to retrieve the data (i. e. the sum per date and type), and then write code to produce your pivot layout. So the query is simply
SELECT datetransact, transactiontype, SUM(transactioncount) AS transactions FROM dummy_transaction GROUP BY datetransact, transactiontype ;

Either the path is correct, or it isn't. This has nothing to do with VMs, the Linux distribution or whatever.
 
If you're trying to use absolute Windows paths on a Linux machine, that of course won't work, because the two operating systems have entirely different filesystem layouts. That's why I suggested to create the paths dynamically based on an environment variable which contains the application directory:
<?php require_once getenv('MY_APP_BASE_DIR').'/path/to/file/within/base/directory'; $_SERVER['DOCUMENT_ROOT'] is usually the wrong answer, because that implies your entire application resides in the document root -- which it shouldn't. Only the frontend scripts like index.php belong there, the core application should be outside of any publicly accessible directory.

Trying to remove security vulnerabilities afterwards is a bad strategy which almost never works. Sooner or later, you're going to overlook a vulnerability or simply give up this tedious task. Instead, use secure programming techniques from the beginning. Don't ever let unsafe values near your SQL queries or HTML markup, not even for a quick prototype.
 
As to the HTML, I strongly recommend you use a template engine like Twig. While it's theoretically possible to generate HTML with plain PHP like people did in the 90s, this almost always ends up in an ugly mess of spaghetti code and XSS vulnerabilities. Twig prevents this by strictly separating the code from the markup, by auto-escaping all input and by providing a much nicer syntax.
 
Stuffing all your functions into one giant functions.php script is also a bad idea, because nobody wants to read through that. Instead, modularize your application. Put related functions into separate scripts.
 
The session and security stuff is copied and pasted from wikiHow, right? Don't do that. A lot of people publishing code on random websites know less about PHP than you do. Copypasta also means the code will never receive any updates and just keep rotting in your application. If you want to use existing tools, pick a trustworthy source (active GitHub projects with multiple contributors are good candidates) and use a mechanism which supports updates (e. g. Composer).
 
In your case, you can simply remove the wikiHow stuff and use the Password Hash API instead.

I would consider using a vector graphic (i. e. SVG) where you can actually rotate the needle with a parameter. This will be a lot less painful than raster image manipulation.

A human-readable version of your query:
SELECT player_details.player_id AS P_id, CONCAT(player_details.Fname, ' ', player_details.Lname) AS pname, positions.position_id, positions.position FROM Soka_player_details_tbl AS player_details JOIN Soka_players_team_tbl AS team_players ON team_players.player_id = player_details.player_id JOIN tbl_season AS seasons ON seasons.SeasonID = team_players.SeasonID JOIN Soka_position_tbl AS positions ON positions.position_id = team_players.position_id WHERE seasons.Publish AND team_players.Team_catId = '1' ORDER BY team_players.position_id ASC ; (untested)
 
Your table and column names definitely need to be improved (rAnDOM ChAnGES oF CHarActER caSE and random tbl_ prefixes and suffixes aren't very helpful). I've used aliases for now.

In your form, there must be a field for the old password. Let's call it “oldpassword”. This is what you need to verify:
if (!password_verify($_POST['oldpassword'], $row['password'])) { // wrong password } ...

The problem with relative paths is that it depends on the environment what the paths are relative to. The current directory could be anything.
 
So do use absolute paths. You can still start with the current script by using the __DIR__ constant:
require_once __DIR__.'/../oldstuff.php'; Another option is to define your own constant for the base directory of the application and start from there:
<?php define('APPLICATION_DIR', $_SERVER['DOCUMENT_ROOT'].'/mninfo'); <?php require_once APPLICATION_DIR.'/oldstuff.php'; Then you don't have to jump around with “..”.

You cannot set cookies after you've generated HTML markup. Cookies are set in the HTTP header, but the markup is in the HTTP body which comes after the header. Once you start sending body data to the client, it's too late to do anything with the header. PHP cannot travel back in time (it can theoretically buffer the message, but this is complex and not recommended in your case).
 
So you have to set the cookie before you generate any page content. There must be no output before the setcookie() call. No <html>, no <head>, not even whitespace. Nothing.
 
As I already said, you need to fix your spaghetti code. I -- again -- strongly recommend you set the cookie with JavaScript. Not with PHP. With JavaScript. If, for some strange reason, that's not an option for you, you'll have to reorganize your PHP script to look something like this:
<?php // this is the first line of the script; there must be nothing before this if (isset($_COOKIE['modal_seen'])) { $show_modal = false; } else { $show_modal = true; setcookie("modal_seen", "true", time() + 3660, "/"); } // now the HTML markup ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <title>Title</title> </head> <body> <!-- ... --> <?php if ($show_modal): ?> <script type="text/javascript"> $(window).load(function(){ $('#modal-box').modal('show'); }); </script> <?php endif; ?> <!-- ... --> </body> </html> I strongly recommend against this. It's just bad programming.

Then use the ID from the URL. Not from the database. The URL. As in:
$id = mysqli->real_escape_string($_GET['tour_id']);

I think I've already told you this several times: You do not apply HTML-escaping or any other manipulation before you insert the data. This effectively damages the input and makes it unusable. For example, the username “I <3 PHP” would become “I <3 PHP”. Good luck doing a text search on that.
 
Escaping is done when you output data, and it must match the specific context. HTML-escaping only works for HTML contexts, shell-escaping only works for shell contexts etc.
 
The functions you've found in that CMS are braindead. You should generally stop using random code from the Internet. Think for yourself.

Yes, but you also need to understand what to replace the percent character with. Right now, you're replacing it with an underscore which stands for “exactly one arbitrary character”. Obviously that doesn't help.
 
If you want percent characters to be interpreted literally, you need to escape them with backslashes:
$search = '%'.str_replace('%', '\\%', $_GET['text']).'%';

$_FILES

You should construct dynamic queries with prepared statements. Not only does this solve a lot of security vulnerabilities. It would also fix your current problem without any extra checks, because if $attributes['id'] is null, a prepared statement maps that to an SQL NULL, which is a perfectly valid value for an auto-incremented integer column.
 
Your code, on the other hand, wraps all values in quotes, so you end up trying to insert an empty string into an integer column.

Just to make sure we agree on the terminology and concepts (because some parts of the original post sound strange to me).
 
With “production server” I mean the public webserver which you have rented (or will rent) to host your website on the Internet. You would never install XAMPP on a production server, because a) XAMPP is meant for developer PCs, and b) it's just not necessary. When you rent a webserver, it usually has Apache, PHP, MySQL etc. already preinstalled, or you can easily install this software with a package manager.
 
The OS on a public webserver must obviously be stable and secure, so common choices are Debian, CentOS, OpenBSD, ...
 
When I suggested a VM, I meant a local test environment to replace your current XAMPP setup. A test environment should match the public webserver as closely as possible. So if your public server uses Debian, Apache, MySQL etc., then you would install Debian, Apache, MySQL etc. in the VM.
 
The VM doesn't need a desktop GUI, because you just use it to run your application. The actual programming still happens on your Windows PC (or whatever it is you're using). If you want a Linux desktop for programming, that's another story.