Jacques1

The code is still far from perfect. While it's great that you're using prepared statements to prevent SQL injections, you haven't done anything about JavaScript injection (aka cross-site scripting). You need to apply HTML-escaping as well. No need for prepared statements when you neither have parameters nor execute the query multiple times; just use PDO::query() in those cases Don't fetch all rows when you just want to iterate over the result set; a PDOStatement itself can be used in a foreach loop. Set a default fetch mode so that you don't have to specify PDO::FETCH_ASSOC over and over again. Don't clutter your code with HTML fragments and inline JavaScript. Keep the different languages separate. <?php const APP_HTML_ENCODING = 'UTF-8'; // enter your character encoding here function html_escape($raw_input, $encoding = APP_HTML_ENCODING) { return htmlspecialchars($raw_input, ENT_QUOTES | ENT_SUBSTITUTE, $encoding); } <?php // application logic goes here $statsStmt = $DB_con->query('SELECT statid, stat_name FROM stats ORDER BY statid'); // end of application logic ?> <!-- now the HTML part --> <select name="stat_id"> <?php foreach ($statsStmt as $stat): ?> <option value="<?= html_escape($stat['statid']) ?>" <?php if ($statid == $stat['statid']): ?>selected<?php endif; ?>><?= html_escape($stat['stat_name']) ?></option> <?php endforeach; ?> </select>

We have the jobs section, but I wouldn't expect too much of it. Paying a competent programmer to repair the entire application may very well cost more than the code itself. I would generally stay away from those code marketplaces. It's very common for people to get ripped off, because the coders are often clueless and won't be held accountable for their mistakes. There are three more realistic routes: Use mainstream software (preferrable open-source); CMS like Drupal, Joomla or WordPress can cover many use cases Hire a real, actual programmer; this will be very expensive Learn to program yourself; this will be very time-consuming

Whoever wrote the code: This is unacceptable, and it's your responsibilty to stop it. You're putting all users, all data and the server at risk. And if this is used for any kind of professional activity, we're talking about legal trouble as well.

You have bigger problems than your mail stuff. Not only is the code wide open to SQL injections. You also allow anybody to reset the password for any account, and that new password is the current time(!). WTF is this?

You cannot set a default filename either (as this could be used to silently upload files with the user's consent).

No, it's not possible, and it would be a major privacy violation if the browser exposed local file paths. How my file system looks like is definitely none of your business. Why do you think you need this?

kthxbye

And what's the purpose of that? Why do you want the other person to see a bunch of dots? Again: Give us the full picture, don't just repeat the same generic one-sentence description. In any case, you don't “send a form”. You can make person A fill out a form, store the data, then make person B fill out a form and finally merge the data. But I have no idea why you would want to prefill the second form with dots.

That sounds a lot more reasonable than the whole exe stuff.

I have no idea what you're asking. Can you explain why you're doing this and how exactly it is supposed to look like? Because this surely sounds weird. Write a coherent description, show some screenshots, ideally post code.

Because that's exactly what the PHP error is all about, for heaven's sake! Do you think PHP displays error messages just for fun? When you get an error message, that means there's really, actually something wrong. You're trying to apply utf8_encode to an array (the one behind the equip key). This is invalid, so you get an error and a nonsense result, namely null. The equip array after applying utf8_decode is null. <?php $before = ['a', 'b']; var_dump($before); $after = utf8_decode($before); var_dump($after); Got it? But none of this matters, because the approach as a whole is wrong (as I've been trying to tell you since the beginning of this thread).

CURLFile

As I already said, you cannot apply utf8_decode() to an array (like the one behind the equip key). It only works with a single string. If you want a recursive version of array_map() or utf8_decode(), your need to implement it yourself. And again: The whole approach is suspect. When you have Unicode text in your database, the PDF should also use Unicode. Have you checked if there's a configuration setting for the character encoding? If there isn't one, have you tried to modify the PDF library? If that's too difficult, have you looked for a better library? A five-second Google search has turned up this workaround.

utf8_decode() transcodes a single UTF-8 string into an ISO 8859-1 string. You cannot apply it to an array. What are you trying to do, anyway? Transcoding all text from the database is a very, very odd approach, especially since ISO 8859-1 can only represent an extremely small fraction of the Unicode character set.

No, the page shows the entire PHP script. Look at the HTML source. Obviously there's something wrong with how you include the charge.php code in the index.php script. That's the part we need to see.

Fumbling with your own date calculation functions doesn't make any sense, because PHP – like every serious programming language in existence – is perfectly capable of doing that itself. And storing timestamps as arbitrary text in the database is plain wrong, as benanamen already said. You use the DATETIME type. If PayPal doesn't provide the right format, you simply parse the input (using PHP's standard library) and then reformat it. So a sane approach to the problem would be <?php // the timestamp formats as used by PayPal and MySQL const PAYPAL_TIMESTAMP_FORMAT = 'G:i:s M j, Y'; const MYSQL_TIMESTAMP_FORMAT = 'Y-m-d G:i:s'; // the input from PayPal $rawNotificationTimestamp = '14:02:30 Aug 20, 2016'; // the parsed timestamp $notificationTimestamp = DateTime::createFromFormat(PAYPAL_TIMESTAMP_FORMAT, $rawNotificationTimestamp); // reformat timestamp for MySQL $dbNotificationTimestamp = $notificationTimestamp->format(MYSQL_TIMESTAMP_FORMAT); var_dump($dbNotificationTimestamp); // get month $notificationMonth = (int) $notificationTimestamp->format('n'); var_dump($notificationMonth); Work with the programming language, not against it.

exec() can capture the return value of the command. Use this. It also looks like you're using a relative path for the executable. Don't do that, because PHP in an IIS context may set the current directory to something you don't expect. <?php exec('/full/path/to/executable ...', $output, $return_value); var_dump($return_value); What's the return value?

MySQL Reference: Date and time types To store a timestamp (i. e. a date and a time), you use the DATETIME type.

That date was back in 2012, so clearly it's not in the future. By the way, storing timestamps as integers is very bad practice. Not only is it very confusing (as you can see). It also makes date calculations a lot harder.

So what is $UsersTable1->action1time? var_dump($UsersTable1->action1time);

$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' ");

The error message says your syntax is screwed up. Now look at the syntax highlighting in your post. Hint: Your double quotes are all over the place. The whole approach is odd. Why on earth do you create a prepared statement with no parameters, execute it once and then immediately drop it?

You can't just insert user input straight into a shell command, because this allows anybody to execute any command on the server (see Command Injection). So the solution is not to change the variables. The solution is to turn your brain on while programming: Do you even need the command? It seems you're posting the data to a remote API, which can easily be done with PHP itself. No need for any executables. If you do need to execute a local program, use a safe method for passing the data. For example, pipe it to the standard input. If this isn't possible, you need to shell-escape the arguments.