mac_gyver

this code is apparently sending either a text or email with a one-time-pin. my guess is it isn't displaying the pin entry page, eventually times out, and redirects to the dashboard page. you would need to show or state what exactly does happen and what you expect to happen. the only things I can tell you based on the posted code are - don't use the @ error suppressor. If you want to test if a variable is set, either use isset()/!isset() or use the Null coalescing operator to condition the input to a default false value. the first header() redirect needs an exit/die statement to stop php code execution, like the rest of the code is using. whatever your inputValidation() function does, it probably doesn't make a value safe to put directly into an sql query. correctly use a prepared query, like the rest of the code is using.

you probably have a redirect-loop or code that's caught in a loop in php. you would need to post all the code, less any database connection credentials, for the login operation and at least the login check code from one of the other pages. btw - the only redirect you should have in your login code should be to the exact same URL of the login page to cause a get request for that page. this will prevent the browser from trying to resubmit the form data should that page get reloaded or browsed back to, where someone can use the browser's developer tools to see what the form data is, even if you prevent the form from being displayed. to allow someone to go to another page, provide navigation links, or put the login form processing/form on any page that needs it.

reload the page after you have opened the network tab.

is this line in getBookedSeats.php or map2.php? at the point where you posted it, the subject was "things being output by getBookedSeats.php"?

just to summarize for anyone reading this. the map2.php code is making ajax fetch requests to get data. the error that is occurring is for a request to - getBookedSeats.php. It is the getBookedSeats.php code that must only output json encoded data. what is the full code for getBookedSeats.php?

if you open the network tab, first, then trigger the request in question, there will be an entry showing the name of the file that got requested. if you click on the file name, you will get a set of tabs, one of which is the Response.

look at the actual response in the browser's developer tools, network tab. the page you make the ajax request to, must only return the json encoded data. there can be nothing else output with that request. if you are not already doing so, the code for any 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 for a page that produces a json response, you would output the response at the end of item #3 on this list, then there would either be no actual html document section or you you would exit/die to stop the php code execution on the page. if none of the replies help solve the problem, just post all the code needed to reproduce the problem, since you have a misunderstanding of what the code should be doing. snippets of the problem don't tell us things like -

if you put the form fields inside a form, and give them array names, you can use the jquery .serialize() method to get the form data using a single line of code - https://api.jquery.com/serialize/ you would use this in the data value in the .ajax call, e.g. data: $(this).serialize(), next, if you put the dynamically to-be added markup inside a <template></template> tag, it is simple to dynamically add it - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template if you put the closing </label> tag after the form field it corresponds to, you can leave out the for='...' attributes and the corresponding id='...' attributes, and make the labels work for the dynamically added fields.

each page must enforce what the current user can do and see on that page, for a non-logged in user, for a logged in user, and for a logged in administrator. if the current user is not logged in, they can only do and see what you have coded on that page for a non-logged in user to do and see. if they are a logged in user and the user ID in the URL is the same as the currently logged in user ID, they can perform actions like editing their own data and seeing all of their own data. if the currently logged in user is a administrator, he/she would be able to pick any user and be able to perform actions like editing that user's normal data and seeing all that user's normal data, and be able to edit/see additional data, such as permissions, edit history, site activity, ip history, ... if you aren't already doing so, your login code should store the user id (autoincrement primary index) in a session variable to indicate who the currently logged in user is. if there is a logged in user, you would query on each page request to get any other user data, such as - username, email, permissions, ...

or you could read the detailed reply you got in your 'proper error handling' thread - https://forums.phpfreaks.com/topic/318166-proper-error-handling/?do=findComment&comment=1615758

you would need to use JSON.stringify({page:2}) for there to be a 'page' element in the decoded data.

here's something that will save you a ton of duplicate effort. client-side validation is a nicety for legitimate visitors. data sent to your web sever can come from anywhere, not just your forms/links/cookies, can be set to anything, despite any client-side validation you may have, and cannot be trusted. you must trim, mainly so that you can detect if a value is all white-space characters, then validate the trimmed data, on the server, before using it. since you must do this on the server, you should either just use the browser's built-in form validation or use ajax to send the piece(s) of data to the server for pre-submission validation, then validate it again, on the server, when the form has been submitted.

most database errors are either due to programming mistakes or a database server that's not running. these type of errors are not recoverable by the user, and the user or hacker on a site doesn't need to know anything specific when these type of errors occur. however, you, as the programmer/developer, do want to know when these type of errors occur. therefore, when learning, developing, and debugging code/query(ies) you would like to display the raw database statement errors, so that you get immediate feedback about problems. when running your application on a live/public server, you would like to log the raw database statement errors, so that you have a record of them, and can find and fix what's causing them. the PDO extension has always used exceptions for connection errors. you should use exceptions for all the other database statements that can fail - query, exec, prepare, and execute. in php8+, the default setting now is to use exceptions for all the database statements that can fail (for both the PDO and mysqli extensions.) you should only catch and handle database exceptions in your code for user recoverable errors, such as when inserting/updating duplicate or out of range user submitted data. the exception catch logic would test the query error number, and setup a message for the user letting them know what was wrong with the data that they submitted, so that they can potentially correct what is wrong, and resubmit the data. for all other query error numbers, just rethrow the exception and let php handle it. for all other types of queries, simply do nothing in your code and let php catch and handle any database exception. when php handles an exception, php will use its error related settings to control what happens with the actual error information, via an uncaught exception error (uncaught exceptions will 'automatically' get displayed/logged the same as php errors.)

the double posted code is the same form, but with a different amount removed for posting by the op. the 13 lines starting with the id="package-step07" div has been additionally removed from the second posting. code doesn't just stop working, so you will need to investigate what is actually occurring. is the form processing code actually getting executed? are there any php errors getting displayed/logged? you will likely need to check with your web server administration as to what is happening with these emails on the mail server. a bunch of recommendations - email can be unreliable. you should store the submitted form data in an database table or a log file so that you have record of the form submissions. the form processing code should NOT copy variables to other variables for nothing. this is just a waste of typing. keep the form data as a set in a php array variable, then operate on elements in this array variable throughout the rest of the code. as a more advanced programming task, if you have more than 2-3 form fields, you should use a data-driven design and dynamically validate and process the form data. you need to trim all the input data before using it, mainly to detect if all white-space characters were entered. after you do item #2 on this list, you can accomplish this will one single line of code. you need to validate all the trimmed input data before using it, storing user/validation errors in an array using the field name as the main array index. 'required' fields must not be equal to an empty string and fields that must have a specific format, such as an email address, must be validated to insure they have that format. after the end of the validation logic, if there are no validation errors (the array holding the user/validation errors will be empty), use the form data. you need to apply htmlentities() to all the submitted form data, after validating it and before using it in an email or in form field values, to help prevent cross site scripting. you must test the return value from the mail() call. if it is a false value, setup a general failure message for the user and log all the relevant data from the request, such as - date/time, ip address, form data, ... the form fields should be 'sticky' and repopulate the field values upon any user/validation errors, so that the user doesn't need to keep reentering data over and over. note: if there are user/validation errors, you would redisplay the form, therefore it should not be inside the else conditional for a post method form having been submitted. if this stopped working, the most likely cause is that it is being used to send spam. by not validating the submitted email address (see item #5 on the above list) and putting the submitted value into the mail header, a spammer can send anything to anyone he wants through your mail server.

nothing i wrote concerns a fixed amount for each fee type. the fee type is the name/meaning of the fee and by submitting the correspond fee_id and storing that, you are normalizing the data, which will result in the least amount of data storage and the fastest queries. the amount field should actually get populated with the current default amount for the selected fee type (i would use data- attributes and some javascript), for those cases where the standard fee will be used.

this is at least the 3rd time someone has stated in your threads to not store derived values. you just calculate them when needed. and if you store the raw data properly, it is a simple and fast query to do so. you should (and probably do) have a student table, which holds the unique/one-time student data. this defines the student_ids. any data related to a student should use the student_id. you should not have any other values from the student table, such as the student_name, in any other table. you should (and probably do) have a semester table, which holds the unique/one-time semester data. this defines the semester_ids. you should (and probably do) have a class table, which holds the unique/one-time class data. this defines the class_ids. you should have a register table, which i suspect is what the invoices table is trying to be, that holds a row for each class, for each semester, for each student. this table defines the class_semester_student_ids that should be used when storing related data, such as invoices, assignments, exams, ... to keep track of the invoice data, per my reply in your previous most recent thread - "you should have a 'fee' table that holds the different type of fees/discounts. you would then have a select/option menu to select the fee type, which submits the fee_id, and the fee amount." you would insert a row for each fee/discount for each class_semester_student_id into an invoice_item(s) table (currently named items_table.) to get the current amount for any or all fee type(s) for any or all class(es), semester(s), or student(s), you would simply SUM() the +/- amounts for the records matching the WHERE term that you build.

where exactly are you getting/seeing the php warnings? in the browser's developer tools network tab, what are 'all' the requests, not just the Fetch/XHR?

your full code is probably doing something like making two requests, one with out data and one with. you would need to post all your code to get specific help with what is wrong with it.

in the network tab, if you click on the URL, which is apparently save_invoice.php, it will show you a list of tabs for the request and response data.

don't unconditionally loop over $_POST data. hackers/bots can submit 100's or 1000's of fields (php had to add a setting to limit the number of fields), with their own field names (which will allow sql injection in the query), not yours. you should instead have an array the defines the expected fields, then use this definition to control what your code does. this is referred to as a data-driven design. see this example - // define the expected form fields $fields = ['easting', 'northing', 'purpose', 'country', 'admin1', 'admin2', 'admin3', 'settlement', 'orig_wellno', 'date_completed', 'coord_sys', 'elev', 'status']; $col = []; // array of columns $data = []; // array of prepared query input values // add the well no $col[] = '`well_no`'; $data[] = $_SESSION['well_no']; // use whatever the actual session variable is // loop over the defining array foreach($fields as $field) { // note: empty considers 0 or '0' to be an empty value. this will prohibit a numerical zero value being used. // you should instead test if the value is or is not an empty string. if($_POST[$field] !== '') { $col[] = "`$field`"; $data[] = $_POST[$field]; } } // build the sql query $sql = "INSERT INTO well_parent (".implode(',',$col).") VALUES (".implode(',',array_fill(0,count($col),'?')).")"; // examine the result echo $sql; echo '<pre>'; print_r($data); echo '</pre>';

the grand total is a derived value. you would calculate it whenever you need it, but do not submit it or store it in the database table. the jquery .ajax success function is called when the ajax request is successful. all this means is that the request and response occurred. when using an ajax request, it is up to your server-side code to build and output appropriate data that the javascript tests for and uses. since you are console logging a fixed 'Invoice data saved successfully.' success message, that is all you know. as @Barand has posted, you can check the browser's developer tools network tab to see what is actually being output by the server-side code. as to the actual problem, which of the commented out lines of code are actually in place? does your insert query list the total_fee_payable column and have a corresponding prepared query place-holder, that's being supplied the correct value when the query gets executed? some other things the code should/should not be doing - you should be selecting from existing students, that are registered for the selected semester, with a select/option menu, possibly with type-a-head, auto-suggest filtering, which i'm guessing you may be doing, since you have some disabled form fields. this should result in a student_semester_id, that you would use when storing related data. you should have a 'fee' table that holds the different type of fees/discounts. you would then have a select/option menu to select the fee type, which submits the fee_id, and the fee amount. you would insert a new row for each different fee/discount for each student_semester_id. the invoice number should be generated by your system, which it may be based on the disabled form field. programing already is a tedious typing activity. if you find yourself repeating code that only differs in its name, it is a sign that you should be getting the computer to operate on the repetitive set of values, instead of you doing a lot of typing. some things you can do that will simplify the code - in the javascript, if you assign a unique class name to the 'fee' fields, you can assign the 'input' event to all the fields with that class name at once, and you can operate on all the values by getting them as a collection and looping over them. you can get all the form field values at once using either the jquery .serialize() method or a javascript FormData object, without writing out lines of code for each field. in the php code, detect if a post method form was submitted, then reference the form data. this only takes one line of code, regardless of how many fields there are. only unchecked checkbox/radio fields won't be set. these are the only cases where you should use isset() statements. don't copy variables to other variables for nothing. this is just a waste of your time typing. keep the form data as a set, in a php array variable, then operate on elements in this array variable throughout the rest of the code. you should trim all input data, mainly so that you can detect if it is all white-space characters, before validating it. after you do item #5 on this list, you can trim all the input data at once, using one single line of code. you should validate all inputs separately, storing user/validation errors in an array, using the field name as the main array index. after the end of the validation logic, if there are no errors (the array holding the user/validation errors will be empty), use the form data. if the insert query could result in duplicate records, your exception catch logic should test for a duplicate index error number, and setup a message for the user (add it to the array holding the user/validation errors) letting them know what was wrong with the data that they submitted. for all other error numbers, just re-throw the exception and let php handle it. if you simply supply an array of the input values to the ->execute([...]) call, you can eliminate all the bindParam() statements. after the end of using the the form data, if there are no errors, you would setup a success response and output it. if there are errors, you would setup an error response, consisting of the all the error messages, and output it. for an advanced programming task, if you have more than 2-3 fields, you should use a data-driven design and dynamically validate and process the data.

the basic jquery dataTable coding is only usable up to a few hundred rows of data, because of the time it takes to send that much data/markup to the client and how much time it takes to manipulate that much data in the client. once you have a lot of real-world data, you need to switch to use server-side processing, where the dataTable is just the User Interface (UI) and the actual work of column sorting, pagination, and searching is done on the server. only the data needed to 'draw' the current page is output to the client. see this link - https://datatables.net/examples/server_side/index.html in any case, if you want to do something like search and find all the orders that use an item, you will need to list all the items in the orders, repeating the common order data in the columns without using rowspans.

so, you actually have a jquery dataTable problem? the dataTable coding assumes that each row has the same significance. any column sorting and pagination is based on the literal rows of data. i suspect that as soon as you put a rowspan with more then one row, that it produces javascript errors. you can check in the browser's developer tools console tab. the question becomes, what are you trying to accomplish? if you want to list all the orders, with column sorting, pagination, and searching, you would only output the unique/one-time information about each order. if someone finds an order that they want to see the details of, they would click on a link and, for example, open a dialog popup with the item details in it. you might (untested) be able to use the jquery dataTable show extra/detailed information api - see this link - https://datatables.net/examples/api/row_details.html If you want to instead be able to do column sorting, pagination, and searching for both order information and item information, forget about the rowspan and just repeat the common information in each row.

we have no idea what you see in front of you. you need to post what result you are getting and what result you expect, for both the case where you have some counter in the code and when you don't.

the links you produce need to start with a copy of any existing $_GET data (so that the original $_GET data is unchanged), set the relevant element(s) in the copy of the data, such as the id element, build the query-string part of the URLs using php's http_build_query(), then produce the link. this will propagate any existing filter, pagination, search, ... terms in the links.