mac_gyver

i played with this some, and the session_name should only contain alphanumeric characters. for the value shown, no session was started. i suspect that on the host where this 'doesn't fail', a session has already been started, the posted code actually does nothing, but php's error related settings are not setup to display/log errors that would be alerting you to the problem.

are you making a https request on your localhost system?

there are existing javascript data-table 'widgets' that will let you click on a heading and sort the rows in a html table for you. if you want to do this yourself, by getting the data from the server-side code, you will need to use ajax. you would have a clickable element in the markup. when clicked it will trigger some javascript code that will make an ajax request to the server-side code, get the data in the order that you want it, build the markup for the tbody part of the table, then replace the existing markup with the new.

your code is displaying the same image, the last one, for all the images, because you are saving each image using only the file extension as the file name, so, assuming they are something.jpg, somethingelse.jpg, ... all the saved files are named jpg, they are overwriting each one when they are saved. you need to save the files with a unique filename.ext that doesn't repeat (and overwrite) any existing file. a simple way of doing this is to insert the row of data, get the last insert id from the query, and use the last insert id as part of the filenames - id.pcontract.jpg, id.passport.jpg the id column you are inserting, from the $_POST['id'] value, what is that? in database designs, you should have autoincrement primary index columns that generate ids that are used for relational data storage and when referencing specific rows of data.

if you are dynamically adding form fields, you should probably be using an array name for the fields, so that you will get an array of submitted data from the set of fields.

you are appending the dynamically created field to the document body, not to the form. i recommend that you do two things - instead of building the markup, line by line, attribute by attribute, put the desired markup inside a <div id='template'>...</div>. you can then just copy the innerHTML from this template element to crate each new element. put another <div id='target'></div> inside the form where you want to append the dynamically created elements. the javascript would them look like this - // create an empty div element var divx = document.createElement('div'); // get the template html and put it into the empty div divx.innerHTML = document.getElementById('template').innerHTML; // append the new div to the target area on the page document.getElementById('target').appendChild(divx);

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.