mac_gyver

these emails are NOT being sent from the email address that is entered in the form (except perhaps during testing when you enter your own email address at your web hosting.) they are being sent from the mail server at your web hosting. the From: mail header MUST correspond to your sending mail server's domain. you can put the entered email address in a Reply-to: mail header, after validating that it is exactly and only one properly formatted email address, to prevent mail header injection. the mail() call is current failing with an error, causing the or die() code to be executed. if you remove that and set php's error_reporting to E_ALL and display_errors to ON, preferably in the php.ini on your system, php will help you by reporting and displaying all the errors it detects. your post method form processing code should - detect if a post method form has been submitted. keep the input data as a set in an array variable, i.e. don't write out code copying variables to other variables for nothing. trim all the data at once. after you do item #2 on this list, you can accomplish this using one single line of code. validate all inputs, storing user/validation errors in an array, using the field name as the array index. after the end of the validation logic, if there are no errors (the array will be empty), use the submitted form data. apply htmlentities() to any value that gets used in a html context, to help prevent any html, css, javascript in the value from being rendered. do not put the raw form data in the subject field. test the returned value from the mail call. if it is a true value, the sending mail server at least accepted the email and will attempt to send it. you would use this condition to display any success message. if it is a false value, it means that the sending mail server didn't accept the email. you would set up a generic failure message for the user in this case. if you are logging all php errors, the error that is returned to php by the sending mail server will get logged. you can also use error_get_last() if you want to specifically get and log the error information. after successfully completing the post method form processing code, with no errors, perform a redirect to the exact same url of the current page to cause a get request for that page. this will prevent the browser from attempting to resubmit the form data. to display a one-time success message, store it in a session variable at item #9 on this list, then test, display, and clear the session variable at the appropriate location in the html document.

it you post all this code on github, less any private settings, someone can have a look at it. things that were previously Deprecated and have been removed in php8 will be producing errors, though if the code is running to the point of producing output, they are at least non-fatal errors. if the code itself is setting the error related settings, anything you do to set them, might be overwritten. this looks like a typical misuse of OOP and from the small amount of actual posted logic, the author(s) misunderstood some of how php even works (the output buffering code in the redirect method does absolutely nothing.) this is a form to email application. are you using multiple user languages? are you using file attachments? it doesn't actually take a lot of code to validate a form submission and send an email.

it's also possible that the method in question is being explicitly called from somewhere within the code, given that it returns a value. there would be a fatal error, which could be hidden in the 'view source' of the output or may be hidden due to php's error_reporting/display_errors settings. if this is the case, you would need to keep the original outputter() method definition, then have the new __construct() method call the outputter() method.

it would take having the entire class definition to determine if this is the cause.

i suspect the code has a method with the same name as the class, where the initialization is/was occurring. such a method no longer gets called automatically when an instance of the class is created. you must specifically supply a __construct() method.

have you checked, using a phpinfo() statement, that it is, because the first posted code should be producing at least a php error. $fullContactInfo is an array of rows, so $fullContactInfo['mentor'] doesn't exist. also, in both pieces of code, the number of prepared query place-holders doesn't match the number of supplied input parameters, which should produce php/sql errors. when you make the database connection are you setting the error mode to use exceptions (which is the default now in php8), setting emulated prepared queries to false, and you should be setting the default fetch mode to assoc so that you don't need to keep repeating it in each fetch statement.

have you determined that the code where the query is at is even being executed, by echoing something at that point? you likely have a typo, but because of all the isset() statements, you are hiding any error messages that that php would give you. except for unchecked checkbox/radio fields, all form fields will be set once the form has been submitted. the only time you should have isset() statements in your form processing code are for checkbox/radio fields. instead of the huge line of isset() statements, just detect if a post method form has been submitted. likewise, all that logic for the $id variable is (probably) pointless. you should also trim all the input data before validating it. you should validate all the data before using it, storing validation errors in an array using the field name as the array index. you should ALWASY list out the columns in the INSERT query. you should get your code to work for one user input form field, then worry about all the code needed for the rest of the fields. if you have more than about 2-3 form fields, you should use a data-driven design, where you have the expected fields defined in an array, along with any validation rules, and any processing rules (is a field used in the insert query, the set part of an update query, the where part of an update query, the where part of a delete query), then loop over this defining array and use simple general-purpose logic to operate on each field, rather than to spend your time writing out repeated code for 38 different fields.

after searching and experimenting, both of the following methods will convert a dynamic unicode code point (the f192, f57f, ... values) to utf8 - $icon = IntlChar::chr(hexdec($c_icon)); // or $icon = mb_chr(hexdec($c_icon), 'UTF-8'); replace the $c_icon with $p_icon, or the literal 'f57f' in the else: branch. this requires removing the JSON_UNESCAPED_UNICODE flag in the json_encode() call.

i can tell you why this doesn't work, but cannot currently tell you a way of making it work. the double-quoted "\u{value}" escape sequence only works for literal values. you cannot use a php variable to supply the value. you could use the evil eval() to do this, but don't.

where did the values in the database originally come from, how exactly were they put into the database table (database extension, any _escape_string functions, any prepared queries), and under what php version? i suspect that the values were double-escaped when they were put into the database and that what appears like a single \ when being echoed is actually two \\ in the values. to check this, see what the 'view source' in the browser of an echoed database value is (without any json_encoding applied yet.)

for the else: logic, with the literal value being assigned to the $icon variable, does it work as expected? does this only not work for database values in $c_icon or $p_icon? btw - JSON_UNESCAPED_SLASHES has to do with / not \ characters.

this appears like it is a mutli-byte Unicode value. it is being escaped by the json_encode() statement. to get this to not happen, add the JSON_UNESCAPED_UNICODE flag as the 2nd call-time parameter in the json_encode() call.

you should never disable any php error reporting level. you will end up missing things that legitimate visitors manage to do that you didn't take into account in your code and discover during testing and things that hackers do in an attempt (that fails or succeeds) to break in. you want to know when these things are occurring so that you can take appropriate action.

no that's not the error number i wrote about (whatever you are using to translate replies into your native language is not working.) that's the raw error message that you DON'T want to output to visitors/hackers since it won't mean anything to a visitor and it is exactly what a hacker wants to see when they intentionally do things that trigger errors. the error number is in the caught exception property ->errorInfo[1]. the specific number for a duplicate index error is 1062. note: there is also a ->getCode() method, which is the sqlstate error number. this however encompasses a number of different related errors, so is not specific to a duplicate index error that you want to setup a message for to let the visitor know what was wrong with the data value that they submitted.

the only database errors that are recoverable by the visitor on a site are when inserting/updating duplicate or out of range visitor submitted data. this is the only case where you should catch and handle a database statement exception, where you would test the error number in the catch logic, for things the visitor can correct, and setup a helpful message letting the visitor know exactly what was wrong with the data that they submitted. for all other error numbers, just rethrow the exception and let php catch and handle it. for all other cases, do not even put try/catch logic in your code. when you let php catch and handle the database exceptions, php uses its error related settings to control what happen with the actual error information, via an uncaught exception error (database statement errors will 'automatically' get displayed/logged the same as php errors.) so, by simply setting php's display_errors or log_errors settings (error_reporting should always be set to E_ALL), you can switch from displaying the raw database statement errors when learning, developing, and debugging, to logging the raw database statement errors on a live/public server. BTW - when you make the connection, you should also set emulated prepared queries to false, you want to run true prepared queries, and set the default fetch mode to assoc, so that you don't need to specify it in each fetch statement.

the format specifier character is a % and the format specifier for a literal % is %, so the result is %%. this is similar to the %s you are also using. the % is the format specifier character. the s is the format specifier for a string argument, resulting in %s.

those values are strings. they will be sorted according to the character order at each position in the string. a '1' at any position in the string, regardless of it being part of '1', '10', '1000000', is less then a '2' at that same position. you can get this to working by padding the values with leading zeros, so that each numerical field in the string is the same length.

the php code still needs the described post method form test, post max size checking, and ['error'] element testing in order to provide a good User eXperience (UX).

there's no field named submit in the form, and even if there was, it won't be included in the form data since it isn't a successful form control at the time the form was submitted, since the form is being submitted via an on change event. i recommend that you instead detect in the php code if a post method from was submitted. i also recommend that you log the $_POST and $_FILES data at the start of the php code so that you can see what is being submitted. none of this has anything to do with the linked to stack overflow thread. also in the php code, if the total size of the form data exceeds the post_max_size setting, both the $_POST and $_FILES arrays will be empty. after you have detected if a post method form was submitted, you must detect this condition and setup a message for the user that the form data was too large and could not be processed. if there is $_FILES data, you must then test the ['error'] element before using any of the uploaded file information. the ['error'] element will be a zero if the file successfully uploaded and can be processed. lastly, since you are using ajax to upload the file, nothing the upload.php file does in the way of redirecting will have any affect on the web page being displayed in the browser. you would want to output failure or success messages back to the ajax code to be displayed in the browser.

sorry for how this sounds, but this code looks like a collection of pieces pasted together that have almost nothing to do with each other, there's missing and mismatched variables, and even an obsolete mysql_error() call in it. is this part of a programming class or self learning? what learning resources have you used to get to this point? next, the most immediate problem, with the text strings being assigned to variables, resulting in the non numerical error messages when you try to add them together, appears like it was intended to be the result of fetching data from the SELECT query. this code isn't even executing that query, nor is it fetching the data from it. do you have a fundamental understanding of the steps needed to build, execute, and fetch data from a SELECT query? without this knowledge, it will be impossible for you to complete this assignment. also, this SELECT query needs a WHERE clause in it to match the unit you are interested in, like the UPDATE query has. have you actually defined what your input data needs to be, what processing you are going to perform on that data, and what result you are trying to produce? regardless of this being a class assignment or a real project, you should NOT update the values to keep track of amounts, since this does not provide an audit trail that would let you know if a programming mistake, accidental key press, or nefarious activity altered the values. you should instead insert a new row of data for every transaction that affects the amounts, just like your bank, credit card, utility, ... does this. here are some suggestions that will modernize and simplify the code - use the much simpler PDO extension. someone has already posted a link to a tutorial on a different help forum where you have posted this. use exceptions for database statement errors and in most cases simply let php catch the exception. this will let you remove any existing database statement error handling logic since it will no longer get executed upon an error, simplifying the code. name the database connection variable as to the type of connection it holds, such as $mysqli or $pdo, then use this variable name throughout the code. this is the cause of the undefined $msyqli variable error. your code is putting the database connection into a variable named $link, not $mysqli. if you are not getting this fundamental requirement of using the same variable for a particular purpose through out the code, you are not going to be able to complete this assignment. don't copy variables to other variables for nothing. just use the original variables that the data is in.

what you are trying to do is dynamically process data using a data-driven design, rather than to write out repeated code and variables for every possible field. if you search the forum for that phrase, you will find some examples. you need a data structure (array, db table) that holds a definition of all the dynamic values associated with each field in a set, such the field name, a human readable label, a type, validation rules, processing rules, multi choice/select values, ... you would then loop over the data in this defining structure and use simple, general-purpose code to operate on the actual data. i typically use the field name as the defining array's index values, since the field name/index must be unique. the label gets used when building error messages, as a label for form fields, as html table headings, e.g. what you mentioned, ... the type is used to control any different processing, via a switch/case statement. validation rules include required validation, format validation, value (range) validation, character class validation. processing rules control being used in an insert query, the set part of an update query, the where part of an update query, in the where part of a delete query, in an email body, in an email header, ...

there's no good reason to create a bunch of discrete variables for a set of data. just keep the data as a set, in an array variable. arrays are for sets of things where you will operate on each member of the set in the same/similar way.

programming languages are like any other language. you have to learn enough of the words and syntax to be able to write and read it, not just repeat things you see. this is where the dictionary/documentation for the language you are trying to use comes in handy.

you need to do this -

yes it is using the PDO extension. you can tell from the fetch mode being used, but this doesn't actually matter, because the database specific code is only querying for all the matching data, then indexing/pivoting it using the parent id value. that's not anything that's specific to the database extension. PDO just happens to have a fetch mode that will do this for you. you do realize that this processing is exactly what i just posted in your other thread, just with different names?