mac_gyver

the most common reason for a password_hash()/password_verify() to fail is because the database column is not long enough to hold the hashed value. another common reason are programming mistakes in the form/form processing code and a lack of server-side validation that results in the hash value not actually being from the password that was submitted in the registration code, or the value being used in the login code not being what you think it is. your post method form processing code should always trim the input data, mainly so that you can detect if all white-space characters were entered, then validate all inputs before using them.

so, i found the problem, with the help of php's error reporting, though the problem is in javascript. you are echoing blocks of static html/javescript using php's heredoc syntax. when I made the test page i used, the javascript was simply in-line. you are using template literals with embedded expressions in the javascript, e.g. ${some_var}. however, in php's heredoc syntax, this is the syntax for a php variable. so, php is putting the last value for any of its variables with the some_var name into the echoed javascript. how i found this is that the embedded expressions in the openUpdateTotalsPopup() javascrpt, for ${width}, ... produced undefined php variable errors. the simplest fix would be to use php's nowdoc syntax. the correct solution would be to NOT echo blocks of static html/javascript, which I see i wrote about in one of your previous threads.

i haven't looked that the code yet, but in Quotes/Edit_Quote_Quantity.php, log the $_GET variables so that you can see how many requests are made to it and what the inputs are - file_put_contents('log.txt',print_r($_GET,true),FILE_APPEND);

a test page works for me (uses the correct quoteItemId matching the clicked button, both in the javascript and in the php code) in chrome, edge, and firefox, but i don't have all the code on your page. the only changes i made to the //loop code is to add a <table> tag before it and comment out the 5 lines with number_format() calls, since i didn't want to make up fake data to loop over for these. do you have some event listener for 'buttons' that could be affecting this? this is acting like some broken markup is causing all those buttons to call the last openEditQuantityPopup(...), instead of the correct one or all the buttons are being clicked and you are seeing the end result from the last such operation. i would console.log the quoteItemId value inside the openEditQuantityPopup() faction, so that you can see how many times it gets called, and with what value as an input. in the end, you will need to post all the code on that page that's necessary to reproduce the problem.

probably this - when you browse to main.php (or is it index.php), do you include the www. on the URL or not and does the URL you use for login.php always include the www. or not? also, since you have shown the full login code, the redirect upon successful completion of the form processing code MUST be to the exact same URL of the login page. this is so that the browser won't attempt to resubmit the form data should that page get browsed back to or reloaded, where someone can use the browser's developer tools to look at what the form 'payload' is and see what the email and password are for the last person to submit the form.

sending a session variable from one page to another involves - having a working, error free, session_start() statement on both pages; have a server properly setup with a folder to hold the session data files; have the session cookie parameters setup so that they match the url for both pages; assign a value to a session variable on one page, that you are sure isn't getting cleared after you have set it, and test for and use the session variable on the second page. except for very overt symptoms, there is not a 'one symptom' is always caused by 'one thing' relationship in programming. if you are expecting someone here to be able to directly tell you what the cause of this problem is, you are mistaken. there are too many possibilities. when something in programming doesn't work, you must find where your code and data are doing what you expect and where they are not. the problem lies between those two points. if all you have done is run your code and notice that the output doesn't exist, you haven't narrowed down the problem. the first step in narrowing down a programming problem is finding any errors that the language is reporting. to do this, you must setup the error related settings and verify that they are actually the values that you have set them to. in your last thread, you would have been getting a fatal run-time error to alert you to one of the problems in the code, but you didn't indicate you were getting any errors. this means that php's error related settings (error_reporting, display_errors, and log_errors) are not setup so that php will help you. once you have set the error settings as i stated, and comment out the redirect, this will narrow down the possibilities, by either producing a error pointing to a problem or if doesn't produce an error this points to where to look at next.

do you have php's error_reporting set to E_ALL and display_errors set to ON, preferably in the php.ini on your system, and you have confirmed using a phpinfo(); statement in your code that these are the values php is using? you can temporarily put these settings into your code, on both pages, immediately after the first opening <?php tag. next, if php's output_buffering is on, and you have a redirect in your code, it will discard any non-fatal errors or debugging output you have added. temporarily comment out the header() redirect so that you can see if there are any php errors up to that point. do you have a session_start() statement in the login.php code? and as is sometimes given, here's a list of programming practices for the posted code - don't use variables ending in numbers. you should completely deal with the result from one block of code before performing another operation, and there's no need to use or to keep track of numbered variables. you should list out the columns you are SELECTing in a query. you need to use prepared queries, instead of putting dynamic values directly into sql query statements. if it seems like using the mysqli extension is overly complicated and inconsistent when dealing with prepared queries, it is. this would be a good time to switch to the much simpler and better designed PDO extension. you need to use php's password_hash() and password_verify() for password handling, i.e. don't store passwords as plain text. the value you store in a session variable upon successful login should be the user's id (autoincrement primary index), and it should be named user_id or similar. you should query on each page request to get any other user data, such as the username or permissions. this is so that any changes made to this other user data take effect on the very next page request after is has been changed, without requiring the user to log out and back in again. the header() redirect needs an exit/die statement to stop php code execution. you could, for example, have some code following the posted code, that's clearing the session variable.

you should do this directly in the sql query statement. MySql has a large number of datetime functions. what is the format of the 'date' column in the database table? if you do this in the php code, you must either compare objects with objects or compare formatted strings with formatted strings, with the same exact format, in a left-right order from most significant field (year) to least significant field (day.) the current php code produces a fatal error at the date_diff() method call, because the 2nd argument must be an object, not the $data["date"] string. $date is a datetime object, you cannot directly compare it with the $data["date"] string. you either must use the datetime ->format() method to produce a formatted string from the $date object, or you must create a datetime object from the $data["date"] string. $diff in a dateinterval object. to get the number of days, you would need to use the dateinterval ->format() method with the '%a' format specifier to produce the whole number of days.

if you post the code generating the array, someone could post an example, instead of just writing about how to do it.

if all you want is a COUNT() per last name, you can do that in the query that's getting the data, with a GROUP BY last_name term. if you want the name data and a count for each last name, i would index/pivot the data using the last name as the main array index when you fetch the data, from wherever it is coming from.

wildcard characters % and _ are only used with a LIKE comparison in a query. if your first query produces any result, it means that you managed to store the % characters in with the data in the database table. preg_match() is a php function. you cannot put it a query to match data in the database table. this query would be producing an sql error. are you using exceptions for errors for the sql queries (this is the default setting now in php8+)? MySql does have regular expressions. see this link - https://dev.mysql.com/doc/refman/8.4/en/regexp.html the regex pattern you came up with matches a string with exactly 3 decimal digits. your stated example is to match 2 digits. which is it and can it vary? what exactly is the overall top-level task you are trying to accomplish, because using regex pattern matching is slow and cannot use indexes, so is a poor choice when you have large amounts of data? lastly, do NOT put dynamic data values directly into sql queries, where any sql special character in a value can break the sql query syntax. use a prepared query instead. if it seems like using the mysqli extension is overly complicated and inconsistent, especially when dealing with prepared queries, it is. this would be a good time to switch to the much simpler and better designed PDO extension.

you are trying to store the data like it is in a spreadsheet, not a database. doing this makes all the code and queries to perform any action on the data overly complicated. it appears that each html table section is for a different type/category of products? within each type/category of product, the testx field is the item id, the testx1 field is the quantity, and the testx2 field is the total? if so, when you store the data in the detail table, you should have a category_id column (that indicates which html table section that data is for), an item_id column, a quantity column, and a total column.

you still have not provided any context (meaning) of this data. name-numbered, labels and variables, are meaningless to us. if the mix of rows shown in the example picture is valid, i.e. you can have have any number of rows from each html table section, you should (probably) store the data from each row in each html table as a separate row in the detail database table, with an item_id column to indicate the meaning of each row of data. i have a recommendation for the dynamically added markup. don't write out the markup in the javascript yourself, where you have to keep it updated to match any changes or corrections (you are going to need to eliminate the use of duplicate ids) you make to the markup being output on the page. instead, define/store the output being output on the page in a php variable, so that you can echo it on the page and echo it as the markup inside the javascript. if you use back-ticks (template literals) around what you echo in the javascript, you can use the exact same markup in both cases. see this link - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

here's a separate list of points for the posted code - use 'require' for things your code must have. include_once, require_once, require are not functions. the () around the path/filename don't do anything and should be removed. every redirect needs and exit/die statement to stop php code execution. the current login check code still allows the rest of the code on the page to run. your form processing code and form need to be on the same page. this simplifies all the code, provides a better User eXperience (UX), and allows you to repopulate the form fields with any existing data so that the user doesn't need to keep reentering values over and over upon an error. this will also let you easily edit existing data when you get to that point. if db.php creates a database connection, why are you also creating a database connection in-line in the code? modern php (8+) uses exceptions for database statement errors by default. with exceptions, there's no need for discrete logic to test if a statement worked or failed and any existing discrete logic should be removed. you should be using prepared queries to prevent any sql special characters from being able to break the sql query syntax, which is how sql injection is accomplished. this will also greatly simplify the sql query syntax. if it seems that the mysqli extension is overly complicated, especially when dealing with prepared queries, it is. this would be a good time to switch to the much simpler and better designed PDO extension. do not query to get the current max() value for a column and use it. this is not concurrent safe. you need to the 'last insert id' function/method/property to get the autoincrement id from the first insert query. do not use any calculated total submitted from the browser. the submitted data can be altered and cannot be trusted. perform any such calculation on the server using data that is on the server. the redirect you perform upon successful completion of the post method form processing code needs to be the exact same URL of the current 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 browsed back to or reloaded. you need to validate the resulting web pages at validator.w3.org ids in the markup must be unique. you should NOT include the id attributes in the addRow markup. if you are not using the id attributes, simply leave them out of all the code. the <label></label> tags are incomplete and not associated with the corresponding form field. the simplest way of correcting this is to put the closing </label> tag after the form field the label corresponds to.

your dynamic addRow javascript only adds a row to the current html table, but the form processing code assumes that all the array form fields have the same number of elements. since your example, using name-number elements, provides no context upon which to help you, you need to decide if you should change the form to dynamically add a row to every html table at the same time or if your form processing code should handle the data from each html table separately, possibly even storing related data in separate database tables. if you care to provide some real world context to this data, we would be better able to help.