mac_gyver

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.

we are not sitting next to you. we don't have all the relevant code. if you won't do the things that have been suggested, we cannot help you. why are not posting the requested code? YOU CAN USE var_export() the way I suggested. this is the current storedata() call - StoreData($StartDate ."-" . $View); // *** Store data to trap this error *** change it to this - StoreData($StartDate ."-" . var_export($View,true)); // *** Store data to trap this error *** throwing random code at the problem won't solve anything. you must find what's causing a problem before you can fix it. you must find what the incorrect value is, then find where and how it is being set to that value. by using all these session variables to make your site 'work', you have created code where values used on one page can get changed by the code on a different page. the solution is to get rid of all the session variables, except for a user id, that identifies who the logged in user is. this 'CounterValue'/view should be a $_GET parameter on the end of the URL, since is determines what will be displayed on a page.

you still haven't done this - so, you don't know what the non-printing value actually is. it is likely an empty string '', not a null value. the null in the "Call to a member function fetch() on null" error is because GetAllData() returns nothing (null) when $View doesn't match one of he 4 values. you haven't posted ../secure/SecurePDO.php or SideMenu.php. where is session_init() defined? it's likely setting $_SESSION['CounterValue'] to the offending value. since this code could be redirecting to index.php and back to statement.php, whet is the full code being used on index.php (which i already asked you to post)? do any of these filenames being required/included exist at different paths within your project, so that different parts of your code could be requiring/including a wrong version of a file? i ask this because in the related code you have posted for this problem, there have been different versions of session_init() and variables being used that haven't been assigned a value in any of the posted code.

this isn't a php version problem. the problem may have always existed, but you just likely have error_reporting/display_errors set to values now that's reporting and displaying this error. note: a nonexistent variable is loosely a false value, so any == or != comparison or if($var) of if(!$var) will logically work. your code could be unsetting it, or you have a character set problem, where either the definition or usage isn't exactly what it appears to be. i would delete and retype one or both lines or copy just those lines into their own file file and run them. edit: here's another possibility - the php code where the definition is at, isn't actually php code, due to the use of a short open tag. if you cannot determine the cause of the problem, you will need to post enough of the code that reproduces the problem.

how are you invoking this? is the code looping over data, and if so what is the code with the looping? approximately how long was the execution time for each of the segments of sent emails? you are using exceptions for errors. when using exceptions, none of the discrete error checking logic will ever get executed upon an error and should be removed. when using exceptions for errors, unless you are doing something special with the error information, you should not catch and handle exceptions in your code. instead let php catch and handle any exception, where php will use its error related settings (error_reporting, display_errors, and log_errors) to control what happens with the actual error information, via an uncaught exception error. php's error_reporting should always be set to E_ALL. if you are invoking this via a browser, you should set display_errors to ON, so that any php detected errors (which will include any uncaught exceptions) will be displayed. if you are invoking this via a cron job/scheduled task, you should set log_errors to ON, so that any php detected errors will be logged.

are you getting an error from the browser about redirecting (it would be a http xxx error number) or is this your - ' Illegal redirection from ...' message? note: require is not a function. the () around the path/filename do nothing and should be removed.

this is unnecessary and is hiding simple typo mistakes. except for unchecked checkbox/radio fields, all other fields will be set/will exist after a form has been submitted. after you have detected that a post method form has been submitted, these 'always set' fields will be set, regardless of what they contain. you only need check if a field is set for checkbox/radio fields. your post method form processing code should - detect if a post method form was submitted - if($_SERVER['REQUEST_METHOD'] === 'POST'). detect if there is $_POST (or $_FILES) data. there may not be if the total size of the submitted form data is greater than the post_max_size setting. 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. trim all the input data, mainly so that you can detect if all white-space characters were entered. validate all inputs separately, 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 is empty), use the submitted form data. after using the form data, if there are no errors, 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 dynamically validate and process form data, and dynamically produce the corresponding form, create an array with the expected form fields, using the field name as the array index, with an array for each field with a label element, field data type, validation rules, and processing rules. you can then loop over this defining array and call general-purpose code to handle each field.

the anonymous function has local variable scope, like any php function. you can add use ($total) to the definition to make the variable available inside the function - $resultsCalcArray = array_map(function($votes) use ($total) { as to the posted code - the input call-time parameter should only be the $id and you should only call this function after you have validated the $id. this function should also have an existing pdo connection as an input call-time parameter. it is the wrong responsibility for this function to make a database connection. there's no point is defining and initializing $conn, $stmt, and $rs. don't use the global keyword to get data into or out of a function. this is not general purpose and results in spaghetti code that is hard to debug problems in. all input data to a function should be supplied as call-time parameters and the function should return the result it produces to the calling code. if you set the default fetch mode to assoc when you make the database connection, you won't need to specify it in each fetch statement. fetchAll() won't ever return a null, so the !is_null() test will never fail and should be removed. since you are only operating on the 'kount' column, that is the only thing the query should SELECT. if you have some reason to select other columns, you can build (or add to) the $resultsCalcArray from just the 'kount' column by using array_column(). you can directly get the total of the $resultsCalcArray 'kount' values by using array_sum(). no in-line code after the throw $e; statement will ever get executed and should be removed. there's generally no point in freeing up result sets, closing prepared query handles, or closing database connections in your code, at all, and there's certainly no point in doing this inside a function, since all those things get destroyed when the function call ends.

you are using ajax to load the content into the sections. what you are seeing is whatever /ajax/latest_news.php returns.

this is apparently the previous related thread - https://forums.phpfreaks.com/topic/321226-pdo-error-on-function-since-a-migration-to-pso at that time, the "Statement.php Lines 14-17" were in a file being included before the session_start() and would never have found the session variable set. i'm going to guess that the "fetch() on null error" was occurring on every page request? you have since moved these lines to statement.php. after reviewing the code you posted previously, if this problem is only occurring occasionally, it is likely due to some auto logout logic, a page auto reload occurring exactly at the point of being logged out, and a timing/race condition in the logic, due to all these session variables. at the risk or repeating myself. the only piece of user related data you should store in a session variable upon successful login is the user id (autoincrement primary index.) you should query on each page request to get any other user data, so that any changes made to this other user data take effect on the very next page request. if you cannot determine the cause of this problem, you will need to post all the current code for statemnt.php, everything being included (you should use require for things your code must have) by statement.php, everything those files are including, and index.php (and everything it includes and everything those files include) since it is involved in the redirects and could be redirecting back to statement.php, less any database credentials or sensitive site information (which should be in a configuration .php file), for anyone here to be able to help.

obviously it is not. you must determine what the non-printing value actually is and find where in your code it's being set to that value. you either have an assignment, instead of a comparison, like i already wrote, or you have some code that's running, such as after a redirect, where you didn't stop php code execution, and it's assigning a value that when echoed is an empty value.

$_SESSION['CounterValue'] may be set, but doesn't contain what you think. either use var_dump() on $view to display what it is or use var_export(), with the 2nd parameter set to true, when you supply it to the StoreData() call to cause it's value (empty string '', null, false, or true) to be used. best guess is you have some code assigning a value to it, using one =, instead of testing the value in it using two == or three ===.

browses cache content by default. on your development system, you must tell the browser to not cache the content of file types that you will be changing often during the development process. your web server likely/should already have a setting that outputs headers for .php files that tell the browser to not cache the content for the request. you need to add the .js and possibly .css/.html file extensions to this. for an apache web server, there would be an entry in the .htaccess file that looks like - <IfModule mod_headers.c> <FilesMatch "\.(php|js|css|html)$"> Header set Cache-Control "no-store, no-cache, must-revalidate, max-age=0" Header set Pragma "no-cache" </FilesMatch> </IfModule>