mac_gyver

have you actually looked at the database table to see if a row is being inserted? is there a hash in the pass column? have you tested what happens when you enter a duplicate user value? is your code displaying the the expected success message? here's a bunch of points for the posted code - use 'require' for things your code must have. include/require are not functions. the () around the path/filename do nothing and should be left out. php's error related settings should be in the php.ini on your system. if you put them in your code, they should be before all other php statements. you cannot set display_startup_errors in your code since php has already started by the time your code runs. the code for any page should be laid out in this general order - 1) initialization, 2) post method form processing, 3) get method business logic - get/produce data needed to display the page, 4) html document you need to validate the resulting web page at validator.w3.org post method form processing code needs to detect if a post method form has been submitted before referencing any of the form data. there's no need for all the logic attempting to detect fields or submit buttons. you need to trim the form data before validating it. you need to validate all input data before using it, storing user/validation errors in an array (which you are doing), 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. after using the form data (which can produce additional errors, such as for duplicate data, ...), if there are no errors, perform a redirect to the exact same url of the current page to cause a get request for the page. this will prevent the browser from trying to resubmit the form data should the page get browsed back to or reloaded. to display a one-time success message, store either the message or a flag value in a session variable, then at the approbate location in the html document, test for this session variable, display the message, and clear (unset) the session variable. the current use of the <label></label> tags is incorrect. if you put the closing </label> tag after the form field it corresponds with, you can leave out the for='...' and id='...' attributes. singleton pattern refers to an OOP class that allows a single instance of the class. this has nothing to do with anything in this code. the $_SESSION['cart'] logic makes no sense, and would either cause this code to loop until php's execution timeout occurs or to skip some of the code. bind_param() requires variables for the data parameters. you cannot supply the result of a function call (password_hash), which produces a php error. this leads me to believe that this part of the code is actually being skipped. if a row is actually being inserted into the database table, the pass value will be empty, not a password hash. because this insert query could produce duplicate data for the user column, the user column needs to be defined as a unique index. you then need try/catch logic for the execution of this query that tests for a duplicate index error number, and sets up a message for the user if the user already exists.

this is a mysqli database extension method. this is a PDO database extension method. you must use statements from the same/single database extension. i recommend that you forget about the mysqli extension. it is overly complicated, inconsistent, and can only be used with MySql/Maria databases. the PDO extension is much simpler, better designed, and the same php statements work with 12 different databases. next, with the PDO extension, you can use implicit binding, and simply supply an array of the input values to the ->execute() call. there's no need for any bind... statements. (for those poster's that would point out that mysqli also has implicit binding, it is not general purpose, doesn't work for all data types, and has you keeping track of when you can and cannot use it, making more work, not less work for the programmer.)

When the web page is messed up, what does the 'view source' in the browser show?

this is a character/string data type. comparisons between strings are character by character, and the character '8' is greater then the character '1'. numbers should be stored in an appropriate numerical (integer or decimal) data type.

programming is easiest when you define what Inputs you have, what Processing you are going to perform on those inputs, and what result or Output you are going to produce - IPO. after you have detected that a post method form was submitted, trimmed all the input data, mainly so that you can detect if all white-space characters were entered, validated that 'required' fields are not empty strings, if the password and confirmation password fields have no validation errors, you would compare the password value with the confirmation password value.

modern php (8+) uses exceptions for database errors by default, for the connection, query(), exec(), prepare(), and execute() calls. if you are not yet using php8+, you should be, but if not, you should set the error mode for the database extension you are using to use exceptions, since this simplifies and future-proofs the code. when using exceptions, no discrete error checking logic will ever get executed upon an error and should be removed. when using exceptions, if execution continues past a statement that can throw an exception, you know there was no error without needing to check the result from the statement. the $_mysql variable in your code is the prepared query statement object. if the prepare() call succeeded (didn't throw an exception), the remainder of your code doesn't need to test $_msyql to know that the prepare() call was successful. the $_mysql variable only indicates that the prepare() call was successful. it doesn't indicate if the row of data was inserted. the username and email (which you are not using in the query) columns must be unique. these need to be defined as unique indexes in the database table. to detect if duplicate data was attempted to be inserted into these columns, you would have try/catch exception handling for the execution of this query, where you would test for a duplicate index error number (1062). since there is more than one unique column, you would execute a SELECT query at this point to find which columns contain duplicate values, and setup a message for the user for each duplicate value. after the execution of this query and the duplicate index error exception handling, if there are no user/validation errors, you know that the row was inserted into the database table. as to the rest of the code and the implementation of the above - the code for any page should be laid out in this general order - 1) initialization, 2) post method form processing, 3) get method business logic - get/produce data needed to display the page, 4) html document. use 'require' for things your code must have. as has already been posted, the post method form processing code needs to detect if a post method form was submitted before referencing any of the form data. note: there are cases where a submit button won't be set (there may not be any $_POST data) and you should not test if it is to determine if you should run the post method form processing code. if you need to distinguish between multiple possible form processing code on a page, use a hidden form field, such as name='action', with a unique value that indicates which form processing code to run. 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. i.e. don't write out line after line of code copying variables to other variables. except for unchecked checkbox/radio fields, all other field types will be set once the form has been submitted. you need to trim all user input data, mainly so that you can detect if all white-space characters were entered, before validating the data. you need to validate all inputs before using them, 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 holding the user/validation errors will be empty), use the submitted form data. after using the form data, if there are no errors (an insert query can produce a duplicate index error for columns that must be unique, such as a username or email address), 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 trying to resubmit the form data should that page get browsed back to or reloaded. if you want to display a one time success message, store either the message text or a flag value in a session variable, then test for this session variable, display the success message, and clear the session variable at the appropriate location in the html document. if there are errors, the code will continue on to display the html document, where you will test for and display any user/validation errors, either all at once or adjacent to the field they correspond to, and redisplay the form, populating the field values with the submitted form data, so that the user only needs correct the errors and can resubmit the form. to prevent errors when populating the field values the first time the form is displayed, when there is no existing form data, use php's null coalescing operator ?? to supply an empty string as the value. any dynamic value that you output in a html context needs to have htmlentities() applied to it, right before or as it is being output, to help prevent cross site scripting. you need to validate the resulting web page at validator.w3.org you need to use <label></label> tags for the form field label text. if you place the closing </label> tag after the field it corresponds to, you can eliminate any for='...' attributes and the corresponding id='...' attributes.

didn't the previous thread show a simple way of doing this? all you would need to do is go from the example code, that loops over and echos the form data, to code that builds and prepares the query, then executes the query inside the loop with each set of form data - // build and prepare the sql query statement $sql = "UPDATE cd006ccals SET ccalcourt=? WHERE ccalid=?"; $stmt = $pdo->prepare($sql); // example code looping over the form data foreach(array_keys($_POST['court']) as $index) { // execute the prepared query with each set of form data $stmt->execute([ $_POST['court'][$index], $index ]); }

you don't want to give hackers useful feedback as to if they were able to cause any specific problem on a site. you also don't want to give legitimate visitors information that they don't need to know and cannot do anything about. database errors are fatal for a page that is database dependent. all you need to let the visitor/hacker know is that the current page isn't working, and you need to log the actual errors. you never want to output the raw errors on a live/public site. modern php (8+) uses exceptions for database errors by default. when using exceptions, no discrete error handling logic in your code will ever get executed upon an error and should be removed, because execution transfers to the nearest correct type of exception try/catch block in your code, or to php if there is no correct type of exception handling in your code. this is the reason why you are not 'seeing' anything when you deliberately trigger a connection error. execution is going to php's uncaught exception handling, where php is using its error related settings (error_reporting, display_errors, and log_errors) to control what happens with the raw error information. php's error_reporting should always be set to E_ALL. on a live/public site, php's display_errors should be set to OFF and log_errors should be set to ON. this will cause all php errors, which includes uncaught exceptions, to be logged. if your server is setup this way, php should generate a http 500 error response. you can setup a custom http 500 page with any information or text on it that you want, such as - this page is not working, the site owner has been notified. please come back later to try again... if you need to handle uncaught exceptions more specifically, such as sending an email or sms when they occur, you can register your own uncaught exception handler - see https://www.php.net/manual/en/function.set-exception-handler.php as to your application code. you should only catch and handle database exceptions for user recoverable errors, such as when inserting/updating duplicate or out of range user submitted data. for all other query errors and all other type of queries, you should do nothing in your application code and let php, or if you have defined your own uncaught exception handler, catch and handle exceptions.

have you examined what the form data is - echo '<pre>'; print_r($_POST); echo '</pre>'; the first field is court. this code would be something like - // example code looping over the form data foreach(array_keys($_POST['court']) as $index) { // for demonstration purposes, echo the values echo 'Court: '.$_POST['court'][$index].'<br>'; echo 'Judge: '.$_POST['judge'][$index].'<br>'; // ... } here's an additional list of points for the code - you can select the database in the connection statement. if the only thing in an overall double-quoted string is a php variable, don't put quotes around the variable at all. if you put the database connection code in its own file, you can just require it when needed and you won't need to redact the connection credentials when posting the code that uses the connection. if the update query can result in duplicate data for any column(s) that must be unique (you would define those columns as a unique index), you would have try/catch exception handling logic in your code, test in the catch branch is a duplicate index error (number) occurred, and setup a message for the user letting them know that duplicate data was submitted. don't echo blocks of static or mostly static html markup. simply drop out of php and put the markup in-line. if you use php's short open print tag <?= and leave out the closing ; right before a closing ?> tag, you can echo php variables in markup using <?=$var?> syntax. you should list out the columns you are SELECTing in a query. a SELECT query that can match more than one row of data needs to have an ORDER BY ... term so that the rows of data are in a specific order. if a query doesn't match any data, output a message stating so, instead of outputting nothing. you can directly loop/iterate over the result object from a query. for what you are doing, you don't need to first fetch the data into $datas. you should always quote html attribute values. you need to validate the resulting web pages at validator.w3.org

the simple way of doing this is to use an array for the data, by using an array name for the form fields, with the array index being the row's unique id, e.g. name='court[{$data['ccalid']}]'. when the form is submitted, you can get the array indexes from the first field (see php's array_keys()), then loop over this array of indexes to access each set of data from the fields. also, you should not put dynamic values directly into sql query statements, where any sql special character can break the sql query syntax. use a prepared query instead, prepared once, before the start of any looping, then simply supply each new set of data when you execute the query. if is seems like using the mysqli extension with prepared queries is overly complicated and inconsistent, it is. this would be a good time to switch to the much simpler and better designed PDO extension. here's a list of general points for the posted code - modern php (8+) uses exceptions for database error handling by default. when using exceptions, no discrete error checking logic will be executed upon an error and should be removed. when using exceptions, your code will only 'see' error free execution. if execution continues past a statement that can throw an exception, you know there was no error without needing any logic to test the result of the statement. if this is the only form that can submit to this page, you don't need to test if the submit button is set. in fact, there are cases where the submit button won't be set and you should not attempt to test if it is. use 'require' for things you code must have. include/require are not functions. the () around the path/filename do nothing and should be removed. to get a form to submit to the exact same url of the current page, leave out the entire action attribute in the form tag. everything in the ...ccal table is for the ccal data. there's no good reason to include 'ccal' in every column name. this is just a bunch of extra typing you have to keep track of. you need to apply htmlentities to all dynamic values being output in a html context to prevent any html entity in a value from breaking the html syntax. textarea's don't have value attributes.

the OP was already told how to use var_export - https://forums.phpfreaks.com/topic/330113-ongoing-problem-with-missing-session-variables/#findComment-1657999 then given a copy/paste use - https://forums.phpfreaks.com/topic/330113-ongoing-problem-with-missing-session-variables/#comment-1659430 edit: and this problem isn't going to go away until the only session variable that is an input to this 'statement' code is the logged in user's id, so that the only code that affects what the processing is and what is displayed on this page, is the code on this page, and not in any processing on other pages.

firstly, this question is a php question. not a mysql question. the syntax of your if() {} conditional statement is broken. the ) is missing. there's no guarantee that the incorrect value is a NULL. i showed you in a previous thread how you can use var_export() to cause the actual value to be used in the storedata(...) call.

it is likely that the sql query is listing the column, but isn't providing a value. you should leave any autoincrement column out of the sql query statement. what is the php code and sql query in question?

YES, you can. var_export() - "Outputs or returns a parsable string representation of a variable" (from the documentation.) what it returns could be assign to a variable, just like you had typed it on the right-hand side of the = in an assignment statement in your programming editor. the first code you have shown in this thread, the error, and value you are logging indicate that the session variable is set, but that it doesn't contain one of the expected values. adding code testing if it is not set won't solve anything. you must find what the incorrect value is, then find and fix the code that's causing that value to be put into the session variable. that this session variable is even named 'countervalue' indicates it is being used somewhere for a different purpose. no wonder it is being randomly changed. OR you can fix the code as i have suggested. if any user can only have a single view, then query the database on each page request to get this value for the logged in user. if a user can select the view from a set of choices, this needs to be handled via a navigation menu and a $_GET parameter on the end of the URL, and validated on each page request to make sure that the value is permitted for the current user.

as a separate post, here is what you actually need to do. you need to start over, update all the code to current standards, organize the code, and have the code for any single operation, such as displaying the statement, on one page. i previously posted this (in fact i'm repeating everything multiple times with you), the code for any page should be laid out in this general order - initialization post method form processing - get/produce data needed to display the page get method business logic - get/produce data needed to display the page html document the only user related session variable should be $_SESSION['user_id'] (autoincrement primary index), to identify who the logged in user is. you should query on each page request to get any other user data, such as the username, role, permissions, ... all user entered input data needs to be trimmed before validating it. all input data to page - $_GET, $_POST, $_FILES, $_COOKEIE, $_SESSION, and some $_SERVER, needs to be validated before using it. if 'required' data is not valid, that's an error, and you would setup and display an error message instead of running code that's dependent on the input data. if input data is optional, and it is not set, you would setup a default value, such as a default view value if there is no view input. your page navigation and the view choice need to be handled using $_GET inputs. here a list of points for the last statement.php and SecureFunctionsBankPDO.php code you posted in this thread - your code should be organized so that you are not repeating yourself. require (and include) is not a function. the () around the path/filename do nothing and should be removed. the list of transaction type/category defined constants should instead be handled via a database table. the global keyword only has meaning inside a function, and even there it should be avoided as it produces code that's hard to debug. every query that has a dynamic value being supplied as an input needs to be a prepared query. due to cross site scripting, even values that come from trusted, logged in users, can be set to anything and cannot be trusted. the discrete logic in MonthlyTakings() will never match $row['Output'], since you are not SELECTing anything named Output. ColourPicker() should NOT directly reference a superglobal variable to get the view. there should be a call-time input parameter for the view. functions should not echo output. they should return the result they produce to the calling code so that the result can be used in any context. don't select all the columns and rows of data from a table just to get a count of number of rows. you should use SELECT COUNT(*) ..., then fetch the count value. don't get a count of the number of rows in a table and use this value as input to another query. this is not concurrent safe. you should not UPDATE a column to keep track of the balance. this can get out of sync with the actual data. you should query the actual data anytime you need to get the balance. the doctype is out of date and needs to be updated. you need to validate the resulting web page at validator.w3.org you need to be consistent. you are using require some places and include elsewhere. you should always use require for things your code must have. as has already been written, you need to use $_GET inputs for navigation, not a post method form. actually, the whole form around the statement content is pointless. you need to use css instead of in-line styling. every dynamic value output in a html context needs to have htmlentities() applied to it right before or as it is being output.