mac_gyver

if this is data you have control over the form markup for, just use array names for the form fields. you will 'automatically' get arrays in the php $_POST data. the reason @Barandasked you to json encode an example of the data and post it is so that we would have something to work with, rather than a print_r output that no one here is likely to take the time to overtype into usable input data.

you must trim and validate all inputs to your code before using them. the $_GET['id'] is a required input. if it doesn't exist, and isn't an integer > 0, that's an error and you should setup a message for the user letting them know that a required input is not valid, and don't attempt to run any code that's dependent upon that input. where is this $_GET['id'] input supposed to be coming from?

have you determined if you are getting data from the api and if so, what exactly does $response look like?

since you are using ajax to make the request to the server-side code, you won't see any output from the web page unless you look in the browser's developer tools network tab. i recommend that you get your code working fully without using an ajax request, then add the ajax code. next, your connection variable is named $pdo, but you are using mysqli statements. you cannot mix database extension calls. you should be using the PDO extension anyways and using a prepared query when supplying external, unknown, dynamic values to a query when it gets executed. also, you should NOT attempt to run a SELECT query to find if data already exists to decide if you are going to INSERT (or UPDATE) data. just define an appropriate unique index in the database table and attempt to insert the data. if you don't care if the data already exists, use the IGNORE keyword in the sql query to prevent a duplicate index error. if you actually want to insert new data or update existing data, look into an INSERT ... ON DUPLICATE KEY UPDATE ... query.

it it's not too much trouble. could this fix be applied to the newest update.

by default, only files with a .php extension will be operated on by the php language engine. the code in for any .php page should be laid out in this general order - initialization post method form processing get method business logic - get/produce data needed to display the page html document the database connection would be made at the earliest point where it is needed, usually in the initialization section. if you are just starting out, the PDO extension is much simpler and better designed then the mysqli extension, especially when using prepared queries, which you should be using when supplying external, unknown, dynamic values to a query when it gets executed.

php has a command named echo. someone asking you to echo a value, means to literally add an echo command in front of a variable so that you can see what value it actually is, and than can show others. this debugging step lets you confirm that you actually have expected values as input for the code to use. the or die(...) output you are getting means that the mail() call failed with a php error of some kind. please review the other replies you have gotten in this thread.

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