mac_gyver

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>

the code for every page (http request) must enforce what the current user can do or see on that page. if you do what i wrote in one of your recent threads - the code performing the admin actions will find that the current user is either not logged in, doesn't exist, or no longer has a role that allows access to the code on that page and the user will be prevented from performing any action.

here are some implementation practices - the form processing code and form should be on the same page. by putting them on separate pages, you are creating a lot of extra code. by only validating one input at a time and not having the form fields 'sticky', you are providing a poor User eXperience (UX). by storing the 'login_attempts' and 'lockout_time' in session variables, a nefarious user/bot can get unlimited new login attempts by simply not propagating the session id cookie between requests. you must store this data persistently on the server in a database table. the only user related value 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 the user data will take effect on the very next page request, without requiring the user to log out and back in again. the way a 'remember me' operation should be implemented is that if the remember me checkbox is checked, at the point of successfully verifying the user's credentials, generate a unique token, store that in a cookie and in a database 'remember me' table that also includes the user id, and the current datatime, for a determining token expiration. on any page request, if the remember me token cookie is set, query to find a matching row in the remember me table. if there is a row and the token is not timed out, use the user id from that row to set the session variable that identifies who the logged in user is. the rest of the code then uses this value in the session variable, just like it was set in the login form processing code. the registration process, unless being performed by an administrator, which your code is not doing, should not include the role. the role should not be something that the user can decide when they register. modern php (8+) uses exceptions for database statement errors by default - connection, query, prepare, and execute. any discrete logic you currently have testing the result of these statements should be removed since it will never get executed upon an error. both the username and email must be unique or you should only use the email and forget about a separate username. the correct way of determining if a unique value already exists in a database table is to define the column(s) as a unique index, just attempt to insert the data, and detect in the exception catch logic for the insert query if a duplicate index error (number) occurred. any form processing code should keep for the form data as a set, in an array variable, then operate on elements in this array variable throughout the rest of the code. i.e. don't write out a line of code copying every $_POST variable to a discrete variable. you need to trim ALL the user supplied inputs, mainly so that you can detect if all white-space characters were entered, before validating the data. you need to use an array to hold user/validation errors, and validate all the inputs at once, storing the errors in the 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. in the login validation logic, all you really care about is that the required inputs are are not empty strings, after being trimmed. by providing additional feedback to a nefarious user/bot, you are helping narrow down the values they need to try.

the above line is missing any { }, so the only line of code that gets executed for an is_dir() is the - echo '<strong>'.$directory .'</strong> <br>'; all the rest of the lines get executed regardless of what $directory is. i recommend that you always format your code so that you can see when it is actually doing.

if you use a cookie or the session to hold this data, it can be bypassed by simply deleting the cookie or not propagating the cookie or session id cookie between requests. you must store this data persistently on the server, in a database table. next, you are not trying to lock the account, you are preventing login attempts for an account, from a device (client type) and its location (ip). if you actually lock the account, it will allow someone to log out and lock out a legitimate user, by just making a bunch of bad login attempts for an account. once you have stored the data in a database table, on each login attempt, you would query to find if, how many, and how long ago the bad login attempts were for the account, for the device (client type) and its location (ip). If the current time is greater than the time limit you have chosen from the last bad attempt, you would process the login attempt.

have you examined what the $_GET data is? echo '<pre>'; print_r($_GET); echo '</pre>';

according to the 1st parameter, you are making a GET request. not a POST request. the main point of my 1st reply in this thread is that your code must validate (all) input data before using it. the account_no input is required (not an empty string), it must consist of a specific set of characters (decimal digits), and it might need to be a specific length or range of lengths. if it is not valid, it is an application error and you should setup and output a useful error message for each of these possible validation steps, and not attempt to use the input data. your first posted code and the code using the null coalescing operator are suppressing any helpful php errors (you would be getting an undefined index error) that would be pointing out that there is no expected entry in $_POST. so, you must change the php code to use $_GET['account_no'], and you must trim, then validate the input before using it. you would only get to the point of testing if the value is in the array of $valid_accounts if the input is valid.

the reason for unusual operation is the ternary operator without a middle term, that the input is probably not what you expect, and php's type casting. when you leave out the middle term in the ternary operator, when the first term evaluates to true, the value used is whatever the first term is, which will be a boolean true due to the empty() statement. instead, your post method form processing code should - detect if a post method form was submitted before referencing any of the form data. detect if there is $_POST data (in case the post_max_size setting has been exceeded.) 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, 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 user/validation errors, use the form data. after using the form data, if there are no user/validation 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 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 it or a flag value in a session variable, then test for, display the success message, and clear the session variable at the appropriate location in the html document. if there are user/validation errors, the code will continue on to display the html document, where you will test for and display any errors, redisplay the form, populating fields with existing data, so that the user only needs to correct the invalid input(s) and can resubmit the form.

i recommend that you validate the resulting web page at validator.w3.org

i don't know what this will look like incorporated into the yii syntax, but this is what i used with just jquery/javascript - // the element that was clicked on var e = $(this); $.post("index.php?r=attendancereport/standard&aid="+$("#academicyearid").val()+ "&ascid="+$("#ascid").val()+"&sid="+e.val(),function(data){ e.closest('tr').find('.s').html(data); });

that's because the current code is looping over the collection of class = s elements, and setting them all to the data that is returned - $(".s").each(function(k,v) { $(".s").html(data); //Populates the Standard drop-down having class .s with the data from the Standard function } ); you need to 'find' the correct class = s element and set it to the data that is returned. take a look at the jquery .parent() method to find a common parent container that all the related form fields are in, then use the jquery .find() method to find the element with class = s.